Sam Gentile enthuses about the availability of the CLR on the Mac. Another thing is that Mac users, like PDA users, appear to be more willing to support small/Micro ISVs. Whether that would hold true for a Silverlight (i.e., non-native) UI, I don't know. But maybe I'll buy my first Mac since the F/X on which I learned Smalltalk circa 1990 (?).  

I'll be listening to this podcast ASAP.

Charles Petzold and Jeff Atwood have gotten in a bit of a kerfluffle that, I think, is an unfortunate example of how online writing can escalate and over-dramatize disagreements between even two talented writers. I'm sure that Atwood appreciates Petzold's work and I'm sure that Petzold appreciates constructive criticism. I'm not going to link to the original posts, because I think that they were both perhaps overly curt and I don't want to fan any flames.

But I do feel strongly enough about the issue to say this: Petzold's Applications = Code + Markup is a very good book. It's dense in a good way (if you've been following the dustup, read the pages in Atwood's original post).

Petzold's work also has a conscious narrative philosophy. Petzold talked about this when he was writing the book. Atwood praises the layout choices made in another book (which I haven't read) and his arguments are credible. But Petzold, too, made deliberate choices on these very issues and I don't think that it's fair to dismiss those choices as if they were accidents of an outdated approach to book design.

That Microsoft was going to increase support for dynamic languages is no surprise: they've been talking about that since (at least) PDC '03 and various hires and initiatives have clearly been in the works. I haven't seen the DLR yet, but my big question is: what version / runtime / patch level of the CLR  and libraries becomes the lowest-common denominator for Silverlight (i.e., cross-platform, in the browser)? Because for better or worse, that becomes the platform for dynamic languages in the .NET world.

I am surprised by the IronRuby announcement (and officially bestow the He-Man Programming Award to John Lam). I really thought we were going to see some form of Ruby#:Ruby::C#:Java. Although I'm happy (Ruby is now my #1 administrative programming language), I was actually hoping to see a new language. Ruby's a fine language, but it doesn't have a good story for concurrence, it has a boring model of XML (unlike VB), it has some unattractive Perl-isms. Most importantly, I think MS does a good job when they have the flexibility to evolve the language and, simultaneously, can devote the resources to developing the compilers, libraries, and toolsets.

Ozzie compared Google's position to Sony's position with the PS2 a few years ago. But doesn't that make IBM Nintendo?

Scott Guthrie just announced IronRuby! Yeehaw!!!!!!

--

Silverlight binding; demoing on Mac

--

Dynamic Language Runtime announced

--

"Shipping later this week" (I'm sure he means shipping a beta / CTP)

--

Uses Ruby naming scheme when programming .NET libraries (weird. Not sure I like that.)

--

"Switch the console into Python mode, Ruby mode, VB mode" (he means something called "Dynamic VB")

--

www.silverlight.net is the commmunity site

(No sign of DLR / IronRuby / IronPython / Dynamic VB on that site as far as I can see)

--

"Componentize dispatching code, code generation, that sort of thing that compiler vendors do" ... namechecks to Hugunin and Lam ... we shipped this morning the DLR source code" on Codeplex ...

(http://www.codeplex.com/Project/ProjectDirectory.aspx?ProjectSearchText=dynamic%20language%20runtime ? )

Voyager is moving at ~17KPS ... divided into 300,000 KPS ... multiplied by 3600 * 24 * 365.25 ... multiplied by 20. ~370,000 years to reach Gliese. To me, a 200-year mission is about what I could imagine our civilization buying into. No way gravity assist can scale; I don't think solar sails scale; no way we're putting enough nuclear bombs into space to do an Orion thing. Lessee... Wikipedia says ion drives have exhaust speeds of ~30KPS ... And this Wikipedia article seems wildly optimistic about "technologies requiring further research" ... Some kind of electromagnetic mass-driver I can imagine (but then, my brother-in-law works at Fermilab, so I'm biased) ...

Update: Surely (?) Dan Ciruli is correct in his comments that without friction, you can go much faster than your exhaust ... So let's say ion drive ... Lessee ... 10^-4 g ... d = 1/2 at^2 ... turnaround at 10 light years ... ~620 years with a peak velocity of 9000 km/sec ... now we're talking ... get a little more acceleration and we're on that planet like locusts on a cornfield.

Just back from a 4-day mini-vacation in Kauai, hiker's paradise (well, if your idea of paradise is a hike in the rain to the world's highest swamp along knife-edge ridges with 3,000' drops...) Looks like I missed lots of interesting goings-on and Mix is going to generate tons of posts, so back to work. In the meantime, you can check out some photos at Flickr.

Michael Suess's fantastic series of brief interviews with concurrence gurus concludes with Microsoft's Joe Duffy (whose own blog is must-reading for performance-oriented windows developers">)contains the intriquing quote in the title. I smell CLR support!

Jonathan Edwards has a great piece of speculation.  Man, if John Lam has produced a native CLR Ruby (maybe based on the IronPython codebase) in 8 months, he'd be the run-away winner of this year's He-Man Programming Award.

Please, feel free to laugh at this column describing how I was completely pwned by hackers trading the German dub of 'Norbit'...

This object, which is of uniform density, is self-righting. It has a second balance point that is "unstable"/highly susceptible to perturbation (when I first read the article I thought it said it didn't have such a point, which freaked me out). I love mathematical objects that are complex and yet arise from (presumably) simple causes (irrational numbers, Julia / Mandelbrot sets, etc.).

My favorite part of the article though, is that the mathematicians noted the similarity of the shape to certain turtle shells. They are now attempting to find if any turtles are inherently self-righting with no leg wiggling. But "It's much work, measuring turtles."

Original post by  Fabian

Benoit Lavigne wonders if ageism is a problem in the software development profession. Oh, hell yeah. From the minute I began editing software development magazines (when I was 25) I began hearing from professionals in their 40s and higher who faced disproportionate difficulty getting work. There is not a question in my mind that this is a real problem. True, this is a field that is unforgiving to those who don't keep their skills current, but I've heard far too many stories to believe that's the only, or even dominant, factor.

Now that I have a touch of gray around the temples myself, I worry about this myself. I'm the oldest person on my programming team right now and I'm at least two decades away from retiring. I have no doubt that it will be harder and harder for me to get work as a developer, no matter how current my coding skills stay. If I'm on the phone with a potential client and they ask about my experiences, I don't say "Professional programmer for 27 years," because I think that could very well trigger ageism; I say "I sold my first program when I was 16."

I fear the day when I'm so old that the only work I'll be able to get will be drawing lines between boxes and pretending I'm delivering value.

Disc Link, a subsidiary of Acacia Technologies Group (an organization that basically buys up patents so that it can sue anyone who violates them), claims that it's patent number 6,314,574 covers hyperlinks from documents stored on a CD that send users to sites on the web.
Last week, Disc Link filed suit against Borland, Business Objects, Compuware, Corel, Eastman Kodak, Novell, Oracle, and SAP, claiming they all violate its patent.

via Download Squad

The patent was filed on Nov 8, 1998.

I first put a hyperlink to the Web on a commercial CD in 1994. (The proceedings of the Software Development Conference. And, yeah, to the Web.) I continued the practice on several subsequent CDs that shipped before '98. I have copies of several of these CDs sitting on my shelf.

I can't see how the claims of the patent cover such links, but if anyone involved in the lawsuit thinks I could be of help, let me know.

Coincidentally, I have a press release in my Inbox from the "Coalition for Patent Fairness" praising the Patent Reform Act of 2007. Maybe, but the bullet item "Reform to make it easier to file a patent application without the inventor's cooperation;" doesn't seem very nice. Intellectual Property legislation has been such a disaster in the past decade that I fear that the only thing worse than the current patent system would be "reform" written by the same people who brought us the DMCA.

Well, looks like I might have to run down to the Post Office after all. The TurboTax filing servers have not been working for hours. I thought that after midnight EST, things might calm down, but I don't know how long to waste before just printing out the forms and taking a trip into town.

Update: The answer turned out to have been "about an hour." Given that the whole point of e-filing is convenience, for which they charge you $34 ($17 for Fed, $17 for State), there didn't seem to be any point in online drama. A big screwup on Intuit's part, but not enough to make me switch products. I have Quicken records going back years and TurboTax is actually a heckuva good piece of software.

DeveloperWorks interviewed Rosalyn Lum and I about the Jolt Awards (IBM was a big winner this year).

Eye-tracking studies by Jakob Nielsen lead to the recommendation "Show numbers as numerals when writing for online readers." This contradicts the traditional style rule of writing out numbers less than 100 (or sometimes 10) (I really had to stop and consciously use numerals for those!).

 One of the reasons that functional programming is worth studying is that it abounds with opportunities for implicit parallelization. As Jon Harrop discusses in this post, the map function takes a function object f and an array [a, b, c, d] and returns [f(a), f(b), f(c), f(d)] (syntax varies from language to language, of course, but you get the point).

The optimist sees this and says "Ah hah! The compiler can simply distribute these calculations to a thread-pool and have a performance advantage on a manycore machine." And this is true if (a) f is quite lengthy or (b) the array is quite large. Otherwise, the overhead of distributing the calculation across cores / processors can very well be greater than performing the map "in core." In the worst case, when function and data are already inside the initial core's cache, the performance hit for distributing it would be very substantial.

This is a familiar theme in programming languages: a theoretical capability runs afoul of implementation realities. The best design decision in Java was "(Almost) Everything's an object": numbers and strings -- the most commonly used data types -- have different semantics (what the .NET world calls "value semantics") because they aren't pure objects. And they aren't pure objects for performance reasons (immutable strings are also good for a couple other reasons). To this day, you can feel an occasional performance hit with pure object-oriented languages (before you flame, keep in mind that I'm about to deploy a Ruby-based service right into the middle of a live multimillion-dollar application and Ruby's not only pure objects, it's interpreted. So I'm not one of those who doesn't understand that performance, productivity, and responsiveness are different things).

Another situation is C/C++'s inline keyword. Structured programming theory tells us not to repeat ourselves -- to define functions rather than writing the same code in multiple places. But in the not-terribly-distant past, the cost of a function call was large relative to local operations (a situation that holds today with some embedded processors). So C and C++ have an inline keyword to say "don't generate a function call for this, generate the code inline." But unlike Java's success with "Everything's an object: almost" the inline keyword turned out to be pretty much a disaster. Now, to this day some people doing embedded systems undoubtedly use inline to great effect. But most developers do a poor job estimating the benefit of the inline keyword. Because, just as distributing map can be counter-productive, inlined code can decrease performance (the on-chip caches of modern processors make code size and data locality very important to performance). (And don't even get me started on template metaprogramming.)

So, what does this history suggest for the manycore era?

• Languages that promise that the solution is "every call's distributed" (or other "pure" approach) will either fail outright to deliver performance gains or will require very sophisticated just-in-time code generators (this is similar to the situation with pure object-oriented languages such as LISP and Smalltalk, where commercial VMs are leaps and bounds beyond academic "proof of concept" interpreters / VMs). The problem with this is that the development of sophisticated JITters requires time and experience, so "the language takes care of it" solutions face a very big chicken-and-egg problem.
• Languages that shift 100% of the burden of parallelization to the programmer (a ParallelAttribute that can be applied to blocks or functions, say) will work in the hands of experts but will be disasters in the hands of the mainstream.
• Some kind of hybrid approach that purists decry as tainted but that solves 80% of the problem (a la Java's "(Almost) Everything's an object") will be the winner.

(No, I don't know what the hybrid approach will be.)

In the way of computers and their miserable antics, my attempts to figure out my system freeze led to a disaster. After determining that my system continued to freeze even when using the "VgaSave" graphics adapter, I began to suspect that it might be my Wireless Network Card (a WMP54GX). I hadn't updated the driver but freezes definitely seemed more common while accessing the Web (causing my initial misguided suspicion of Firefox) and background behavior could additionally trigger network access for the other, seemingly random freezes.

So, using Device Manager I disabled my network card. I rebooted and the system had lost my identity. That is, somehow, c:\documents and settings\larry was not-quite-deleted, but I think all of its sub-directories were. All of my start programs, desktop, settings, etc. were gone. Further, so too were directories gone from the 'all users' account. And there was something weird about the registry -- when I tried to switch "View options" in Explorer (so I could see hidden files and show extensions and all that sort of stuff), it "wouldn't take." As if data wasn't being properly written into the Registry under CURRENT_USER.

So that kind of sucked and I played around for a bit before deciding that the system was so screwed up that I had to take the ultimate risk -- restoring from backups. I have Acronis TrueImage on a daily backup to an internal drive. I pointed at the OS partition (I have partitions on various drives for OS, bin (Program files), data, media, and a non-backed-up "volatile" partition) and chose a restore point of last Thursday, before the freezes started. Acronis rebooted into itself and a few hours later told me it was finished.

I think this is the first time in my life that an emergency restore worked perfectly: the very stuff that I had lost came back and because I keep my data on another partition, I didn't even lose any email. I may have lost some files I'd temporarily stored on the Desktop, but otherwise, I feel like the luckiest guy on Earth. Now all I have to fear is my deep suspicion that the problem was caused by some auto-update facility.

So... Acronis TrueImage 8 (I think they're up to 9 or even 10 now) on a daily backup to an internal SATA drive. (N.B.: If I'd relied only on RAID, I'm fairly sure I would have been screwed.)

OK, back to posting about software development issues, I promise...

My system has begun locking up and the circumstantial evidence, much to my surprise, seem to point to Firefox. The lockup is a hard one: the screen freezes with no mouse response, no perfmon counters, no hard drive activity. Have to go to the big red switch. I recently re-installed my display drivers (for an ATI All-In-Wonder 800) using the latest Catalyst drivers and normally I would strongly suspect them. But it seems to me that the hangs are at least often and perhaps always occuring right at the moment of switching pages in Firefox. (It just did it as I checked that I was running Firefox 2.0.0.3.)

Now, opening pages in a browser is a common task, so it's possible that this is pure coincidence. Too, I've had hangs when I wasn't opening pages, but I very well may have had the browser open and experiencing an auto-refresh (such as happens on my homepage, which is msnbc.com). Nor does this let my display driver entirely off the hook, as the problem may relate to the display-rendering of a just-changed Web page, right?

So, after two days of drastic msconfig work, I am ready to try the ultimate sacrifice -- switching to IE. Wish me luck.

Update: Well, the good news is that it's not Firefox. Fifteen minutes into a Firefox-less session, I got the freeze. I feel it must be the display drivers, but I don't know what alternatives I have.

Todor Georgiev, a scientist at Adobe, has etched a lens so that it creates many images. "Software merges the mini-images into a single image that the photographer can focus and refocus at will." (Link to BoingBong report, not original, which may be BoingBoinged/Slashdotted.) So that's what we'll be using manycore machines for.

I had always assumed that the compound eyes of insects and mantis shrimps consisted of a gazillion separate lenses and retinas. If I read this abstract correctly, that seems to be true, at least for our friend the mantis shrimp. But that which Adobe can do in software nature can exceed. Some animal eyes are just pinhole cameras (such as, apparently, that of the white crappie). But what if you had two (or a gazillion) pinholes projecting onto the same retina?

The advantage, you'd think, would be that you'd get the higher resolution of a big retina (the data fro