For those as confused as I was: "x^" is how the author renders "x̂" (or x-with-circumflex, for the font-challenged).

Something seems to be wrong with how Chrome renders this: http://imgur.com/a/z1tLz

Funny, works fine on mobile Chrome: http://imgur.com/ZZseIyB

It actually works fine for me on Chrome on Linux if I change the font to almost anything but Verdana. The mobile Chrome screenshot seems to be using Roboto, so that would explain the difference.

A bug in Verdana (as it seems to affect Firefox on Linux too)?

Is it even op to the font to decide this? It seems that there's some confusion about whether it should combine with the previous or the following character.

Combining characters are defined (in Unicode, at least) to always combine with the previous base character.

Power budgets for software are already a thing that exists. It's not just about stuff getting cheaper and faster -- portable/battery-powered devices are becoming increasingly important.

So you're right, but not only for the reason that you think you're right :-)

Can you use 8.6? TclOO makes objects a lot more wieldy: they're still commands, but you get automatic cleanup, destructors, some nice options for inheritance/delegation and so on.

"emulating objects with procs" sounds like you're not taking advantage of any of the previous OO extensions (snit, itcl, xotcl ...), which has to be making life harder than it should be :(.

Unfortunately I'm stuck with the embedded 8.5 interpreter.

And, to be entirely honest, most of the gripes above are likely more due to the poorly designed API than to the language itself.

> Not a week goes by I don't have to wrestle with one of my legacy tcl scripts

That's an odd thing to say ... I've seen Tcl written last century that runs unmodified on 8.6. Why are you wrestling with legacy scripts?

I make business desktop software in Tcl/Tk. That it keeps me out of the hype cycle is gratifying, but it's also a damn well engineered and productive environment (I could go on for hours ...).

> just set your browser to the width you like?

Thank you for saying it. This "fixed-width-in-pixels" thing that has taken hold completely baffles me.

And then a site adds a sidebar and it all breaks.

The variation I keep seeing today is sites that lose any left margin at all when the browser is less than 1000px wide (or 930 or whatever magic number the designer had in mind that week).

It's pretty special seeing text butted up hard against the left margin. I'm glad the proliferation of web standards has advanced to the point that this is acceptable!

First I've heard of unexec() -- while it sounds like a good thing to be rid of, I'd be quite interested to read about its design and perhaps past implementation challenges. Anyone aware of a good tech article on it?

Under what language / toolkit? Folks are pointing out counterexamples below and I could name a few myself, but I'm curious where you're coming from :-)

Bear in mind that this was written in 1981, at the beginning of a decade that saw enormous progress for Pascal, rendering most of "some guy"'s objections invalid. ANSI C only happened towards the end of that decade.

I think when an essay from 20 (or 35) years ago claiming "X sucks" is referenced, it's kinda foolish not to draw attention to the history that followed.

Well, I was using Pascal professionally from 1986 to 1988, and many of those objections were still valid. (Granted, on an embedded system rather than a PC, so the improvements in Pascal were slower in coming to us.)

I was using pascal in the early 90s, and the compilers to which I had access most certainly still had "Strongly typed, but arrays of different lengths are different types", which was incredibly annoying. (And for fun, consider the arguments against pascal's length-typed arrays and against go's lack of generics)

> The most severe of the vulnerabilities could allow remote code execution if an attacker is able to log on to a target system and run a specially crafted application.

That reads to me like "RCE if you have RCE". Which I guess is a fair description of the DLL vulnerabilities if you ignore the privilege-escalation parts.

The DirectShow and (perhaps) passwordless RDP vulnerabilities seem rather more severe to me.

How is that leader quote appropriate?

It seems like basically a local elevation of privilege. Useful to malware and/or wayward secretaries.