Chad Perrin: SOB

30 December 2006

cursquaround parenthebrackaces

Filed under: Geek — apotheon @ 03:07

I keep seeing some oddly varied and contradictory terms used to describe paired delimiter characters used in programming. Specifically, I see a lot of people using incorrect terms to refer to braces, brackets, and parentheses.

Sometimes, I hear people refer to “square brackets” and “curly braces”, which is fine, if a bit clumsy and redundant. At least they’re applying the correct terms to the correct delimiters. What really gets my goat, though, is when someone uses one term for everything — like “round brackets”, “square brackets”, and “curly brackets”. Once or twice, I’ve even seen people obstinately arrange to use the wrong terms for everything, all at once. An example that leaps to mind is a paragraph I came across one day on the Internet where someone referred to round brackets, curly brackets, and square braces. Como se huh? WTF, mate?

I say again, Whiskey Tango Foxtrot, over.

For those few of you programmatically inclined netizens who actually read my words here from time to time, here’s a quick and handy guide:

Parentheses are those curved things above the 9 and 0 keys on an American English qwerty keyboard layout. This is an open parenthesis: (

This is a closing parenthesis: )

Those are not frowny and smiley faces.

Brackets are those things made up of straight lines and corners that, on American English qwerty keyboards, are the next two keys to the right of the P key. This is an open bracket: [

This is a closing bracket: ]

They are not frowny and smiley robot faces.

Braces are the curly and pointy things that you reach by using the Shift key with the bracket keys on American English qwerty keyboards. This is an open brace: {

This is a closing brace: }

I don’t even want to know what you emoticon worshippers think those might be.

In Perl (for example), braces are used to enclose blocks of code and define lexical scope as well as to identify hash elements, brackets are generally used to define array elements and regex character classes, and parentheses are mostly used for expression grouping and (when you feel like it) enclosing the arguments of functions and certain function-like operators. Try to avoid getting them mixed up. Doing so can ruin an otherwise perfectly good program — and every time you misidentify them in conversation with other programmers, you increase the likelihood that someone else will screw up a perfectly good program.

Think of the children.

(This is cross-posted to Geekend.)

22 December 2006

Debian Etch moving to Stable release soon

Filed under: Geek — apotheon @ 08:13

If you’re using Debian Etch/Testing or Sarge/Stable right now, you’re about to see a change in the Debian APT archives as Etch becomes the new Stable release, and Sarge becomes a legacy release. In fact, this was already supposed to have happened on the Fourth of December, but delays encountered by the Debian core dev teams have pushed it back a bit. Etch is now “frozen”, only accepting compatibility, functionality, and stability fix updates from package maintainers until Etch is moved into Stable. This means that the Stable release of Etch is imminent. Because of this, your software management world might get a little shaken up. There are some simple ways to handle this, however:

  1. If you’re using Debian Etch/Testing, you could avoid the turmoil that comes with continued use of Testing by following Etch into Stable. You do this by editing your sources.list file (located at /etc/apt/sources.list). When a new release moves into Stable, the previous Stable release moves into legacy support and the Testing branch undergoes a serious shake-up that can result in broken software updates and a wedged APT system, off and on, for a couple months before the new Testing release is fully settled in. I’ve dealt with this in the past, and will not deal with it again. To avoid this problem, and follow the Etch release into the Stable branch, just find all entries in your sources.list file that refer to the testing branch and change the word “testing” so that it says “etch”. Nothing will change now, and you’ll basically never notice the change when it does happen except that you will not see software updates nearly as often in Stable as you did in Testing. If, at a later date, you want to move back up to Testing (when you’re reasonable sure Testing has stabilized), you can then change it back to Testing and do an apt-get dist-upgrade to bring everything up to speed with new software versions. You’re probably better off sticking with the same release version, though, and using apt pinning if you need a specific higher-number version of a given piece of software.
  2. Similarly, if you’re using Debian Sarge/Stable, you should ensure that any entries in your sources.list file that refer to “stable” are edited to say “sarge” instead. This will allow your system to move gracefully into legacy support, which (if I recall correctly) lasts three years. As I learn more about the GPL, I begin to suspect that the three year number was not arrived at by accident — it’s probably part of a plan to conform strictly to the three-year source availability clause of the GNU General Public License. Similarly to the Testing situation, you may find that you wish to move out of legacy and back into the Stable branch after the version release shakeup settles down. Stable will see considerably less of a shakeup than Testing, but it may still behoove you to wait a few weeks before upgrading from Sarge to Etch. To do so, of course, you can just change your sources.list entries to suit and do an apt-get dist-upgrade when you’re ready.
  3. Finally, there’s my favorite choice, which I will be using in the near future wherever I find that it’s not an unreasonable burden: do a fresh install of FreeBSD, or whatever else you want to use (the next Debian Stable or Testing version included in the list of options). If you’re following Etch into Stable, there’s really zero need for this, but otherwise you may discover eventually that you’re better off with a fresh install, in part because this will prompt you to be damned sure your critical data is safely backed up before fiddling with release version updates during the release cycle’s culmination. Specifically, I’m migrating as much as I can within limits of my own laziness in the near future from Debian to FreeBSD. Your mileage may vary.

Quick Definitions: Type System Characteristics

Filed under: Geek — apotheon @ 02:00

There’s a lot of confusion floating around on the Internet over the subject of type system characteristics. People seem to have a lot of difficulty agreeing on the meaning of terms like “statically typed” and “type-safe”. The most difficult for people to agree on, however, seems to be “strongly typed” (and, by association, its antonym: “weakly typed”). Many people, it seems, have come to the conclusion that the only way to deal with the situation is to discard any use of certain type system characteristic terms entirely, because they are effectively “meaningless” due to the ubiquity of disagreement and misunderstanding.

Of course, that’s an absurd approach to take. If you just discard type system terminology that allows you to differentiate between type systems, you cease to be able to differentiate. Such differentiation is often important to being able to understand what you’re doing when programming, or choosing a programming language for a given task. Understanding the type system characteristics of a given language is as important as understanding the primary programming paradigm of the language, notational rules, semantics, naming conventions, and any other characteristics of a given language.

Worse yet, I have heard it said that various type system characteristics are actually just “implementation details”, rather than actual characteristics of the language. The truth is that actual type system characteristics are reflected in the language’s syntax — if you change the implementation from, say, runtime typing to compile-time typing, you change the language from dynamically typed to statically typed. This, in turn, alters the language: in such a circumstance as changing the implementation from enforcing dynamic to static typing, you impose a requirement for either type notation or type inference semantics, for instance. You may also fundamentally alter type safety, if nothing else about the language changes, and may eliminate certain forms of polymorphism that are not compatible with the language’s syntax and semantics in a statically typed context.

Given time and thought, over a period of some years, I’ve arrived at a fairly firm and internally consistent understanding of what various terms for type system characteristics mean. The definitions of these common terms, as I understand them, are orthogonal to each other and individually meaningul. They agree with the statements of recognized experts who have cause to know what they’re talking about, they eschew the largely meaningless bleatings of people just trying to make a given language sound better than another, and they agree with clearly understood interpretations of the actual English language meanings of the words used. Here they are:

type-safety: A type-safe language is one whose core type system does not allow for type errors at runtime. Such a language is almost impossible while still being a useful general-purpose language, but many languages come close enough to warrant the term “type-safe” for common usage. By contrast, a type-unsafe language in its purest meaning is one that does nothing to prevent type errors at all.
statically typed: A statically typed language is one that determines types at compile time. By contrast, a dynamically typed language is one that determines types at runtime, generally based on context.
strongly typed: A strongly typed language is one that does not allow the programmer to simply dodge the type system and where any instantiated or applied datum has a given type that cannot be changed, explicitly or implicitly. By contrast, a weakly typed language provides casts, bit manipulation, and other in-place conversions or evasions to subvert types.
duck typing: This is a more recent term than these others related to typing, and arose with the Ruby community. It essentially refers to a language that allows for a type to be unset until the datum to be typed has a typable value, at which point the type is “obvious” and set in stone. The most common implementation of this uses dynamic typing, but there are static type systems that could be called “duck typed”, such as OCaml and Objective C — though in OCaml’s case, it is achieved through type inference, and in Objective C it is limited to object types and is determined by behavior rather than type inference.

That makes OCaml type-safe, statically typed, strongly typed, and arguably duck typed (depending on how you use it). It also makes Ruby duck typed, type-safe, dynamically typed, and strongly typed; it makes Perl type-safe, dynamically typed, and strongly typed; it makes C statically typed, weakly typed, and kind of half-assed type-safe if you’re careful; it makes C++ less type-safe, weakly typed (though slightly more strongly typed than C), and statically typed, as well as allowing you to fake duck typing via templates and the like; it makes Objective C statically typed, exactly as half-assed type-safe as C, half-assed strongly typed (more so than C or C++), and duck typed insofar as its object system is concerned; it makes PHP weakly typed, dynamically typed, and type-unsafe; it makes Java fairly type-safe, weakly typed, and statically typed; and it makes Pascal statically typed, weakly typed, and mostly type-safe.

At least, that’s what comes to mind off the top of my head.

Older Posts »

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