In answering a reader question about Flash today, I linked to Adobe’s November press release and I commented:

Granted, Adobe says it’s abandoning Flash ‘only for new mobile device browsers while still supporting it for PC browsers.’ This is still a painful statement because [in part] … the distinction between mobile devices and PCs is quickly disappearing as of this year as PCs are becoming fully mobilized.

But what’s a “mobile device” vs. a “PC” as of 2012? Here’s a current data point, at least for me.

For almost two weeks now, my current primary machine has been a Slate 7 running Windows 8 Consumer Preview, and I’m extremely pleased with it. It’s a full Windows notebook (sans keyboard), and a full modern tablet. How do I slot it between “mobile device” and “PC,” exactly? Oh, and the desktop browser still supports Flash, but the tablet style browser doesn’t…

Since I’ve been using it (and am using it to write this post), let me write a mini-review.

I loved my iPad, and still do, and so I was surprised how quickly I came to love this snappy device even more. Here are a few thoughts, in rough order from least to most important:

• It has a few nice touches that I miss on iOS, like task switching by simple swipe-from-left (much easier than double-clicking the home button and swiping, and my iPhone home button is started to get unreliable with all the double-clicking [ETA: and I never got used to four-finger swiping probably in part because it isn’t useful on the iPhone]), having a second app open as a sidebar (which greatly relieves the aforementioned back-and-forth task-switching I find myself doing on iOS to refer to two apps), and some little things like including left- and right-cursor keys on the on-screen keyboard (compared to iOS’s touch-and-hold to position the cursor by finger using the magnification loupe). In general, the on-screen keyboard is not only unspeakably better than Win7’s attempt, but even slightly nicer than iPad’s as I find myself not having to switch keyboards as much to get at common punctuation symbols.
• I was happily surprised to find that some of my key web-related apps like Live Writer came already installed.
• The App Store, which isn’t even live yet, already had many of my major apps including Kindle, USA Today, and Cut the Rope. Most seem very reliable; a few marked “App Preview” are definitely beta quality at the moment though. The Kindle app is solid and has everything I expected, except for one complaint: It should really go to a two-column layout in landscape mode like it does on iPad, especially given the wider screen. Still, the non-“preview” apps do work, and the experience and content is surprisingly nice for a not-officially-open App Store.
• Real pen+ink support. This is a Big Deal, as I said two years ago. Yes, I’ve tried several iPad pens and apps for sort-of-writing notes, and no, iOS has nothing comparable here; the best I can say for the very best of them is that they’re like using crayons. Be sure to try real “ink” before claiming otherwise – if you haven’t, you don’t know what you’re missing. iPad does have other good non-pen annotation apps, and I’ve enjoyed using iAnnotate PDF extensively to read and annotate almost half of Andrei’s D book. But for reading articles and papers I just really, really miss pen+ink.
• All my software just works, from compilers and editors to desktop apps for full Office and other work.
• Therefore, finally, I get my desktop environment and my modern tablet environment without carrying two devices. My entire environment, from apps to files, is always there without syncing between notebook and tablet devices, and I can finally eliminate a device. I expected I would do that this year, but I’m pleasantly surprised to be able to do it for real already this early in the year with a beta OS and beta app store.

I didn’t expect to switch over to it this quickly, but within a few days of getting it I just easily switched to reading my current book-in-progress on this device while traveling (thanks to the Kindle app), reading and pen-annotating a couple of research papers on lock-free coding techniques (it’s by far my favorite OneNote device ever thanks to having both great touch and great pen+ink and light weight so I can just write), and using it both as a notebook and as a tablet without having to switch devices (just docking when I’m at my desk and using the usual large monitors and my favorite keyboard+mouse, or holding it and using touch+pen only). It already feels like a dream and very familiar both ways. I’m pretty sure I’ll never go back to a traditional clamshell notebook, ever.

Interestingly, as a side benefit, even the desktop apps are often very, and more, usable when in pure tablet+touch mode than before despite the apparently-small targets. Those small targets do sometimes matter, and I occasionally reach for my pen when using those on my lap. But I’ve found in practice they often don’t matter at all when you swipe to scroll a large region – I was surprised to find myself happily using Outlook in touch-only mode. In particular, it’s my favorite OneNote device ever.

By the end of this week when I install a couple of more apps, including the rest of my test C++ compilers, it will have fully replaced my previous notebook and my previous tablet, with roughly equal price and power as the former alone (4GB RAM, 128GB SSD + Micro SD slot, Intel Core i5-2467M) and roughly equal weight and touch friendliness as the latter alone (1.98lb vs. 1.44lb). Dear Windows team, my back thanks you.

So, then, returning to the point – in our very near future, how much sense does it really make to distinguish between browsers for “mobile devices” and “PCs,” anyway? Convergence is already upon us and is only accelerating.

David Braun asked:

@Tom @Herb: What’s so wrong with flash that it should be boycotted? Have I been being abused by it in some way I’m not aware of? Also,does HTML5 have any bearing on the subject?

I’m not saying it should be boycotted, only that I avoid it. Here’s what I wrote two years ago: “Flash In the Pan”.  Besides security issues and crashing a lot, Flash is a headache for servicing and seems to be architecturally unsuited for lower-power environments.

Since then, two more major developments:

1. Even Adobe has given ground (if not given up).

Adobe subsequently abandoned Flash for mobile browsers and started shipping straight-to-HTML5 tools.

Granted, Adobe says it’s abandoning Flash ‘only for new mobile device browsers while still supporting it for PC browsers.’ This is still a painful statement because:

• it’s obvious that ceding such high-profile and hard-fought ground sends a message about overall direction; and
• the distinction between mobile devices and PCs is quickly disappearing as of this year as PCs are becoming fully mobilized (more on this in my next blog post).

2. We’re moving toward plugin-avoiding browsing.

Browsers are increasingly moving to reduce plugins, or eliminate them outright, for security/reliability/servicing reasons. Moving in that direction crease pressure or necessity to either:

• ban Flash (Mobile Safari, and Metro style Internet Explorer 10); or
• deliver Flash built into the browser itself (even for plugin-allowing browsers like Chrome).

I’m not saying Flash will die off immediately or necessarily even die off entirely at all; there’s a lot of inertia, it’s still useful in many kinds of devices, and it may well hang on for some time. But its architectural problems and current trajectory are fairly clear, and it’s been months since I’ve heard someone complain that certain people were just being unfair – Jobs’ technical points are on the right side of history.

While spelunking through the code of a new project you recently joined, you find the following factory function declaration:

widget* load_widget( widget::id desired );

JG Question

1. What’s wrong with this return type?

Guru Questions

2. What is the recommended return type? Explain your answer, including any tradeoffs.

3. You’d like to actually change the return type to match the recommendation in #2, but at first you worry about breaking source compatibility with existing calling code; recompiling existing callers is fine, but having to go change them all is not. Then you have an “aha!” moment, realizing that this is a fairly new project and all of your calling code is written using modern C++ idioms, and you go ahead and change the return type without fear, knowing it will require few or no code changes to callers. What makes you so confident?

The solution to GotW #103 is now live.

Earlier this week, Brent Schlender published selected Steve Jobs quote highlights from his interview tape archives.

Here’s one about us:

The difference between the best worker on computer hardware and the average may be 2 to 1, if you’re lucky. With automobiles, maybe 2 to 1. But in software, it’s at least 25 to 1. The difference between the average programmer and a great one is at least that.

This illustrates that there’s always lots of headroom to keep growing as a developer. We should always keep learning, and strive to become ever stronger at our craft.

You might also enjoy the history and observant commentary in Schlender’s other new article The Lost Steve Jobs Tapes, which focuses on “the wilderness years.”

Last week at the Lang.NEXT 2012 conference in Redmond, I gave a 40-minute C++ talk and participated on a native languages panel. Both are now online at Channel 9.

Here’s the 40-min C++ talk, taken from the C9 site:

(Not Your Father’s) C++
Herb Sutter 

What makes ISO C++11 "feel like a new language"? What things that we know about past C++ do we need to unlearn? Why is C++ designed the way it is – historically, and in C++11? Finally, what is the difference between managed and native languages anyway, and when is each applicable? This talk gives an overview and motivation of modern C++ and why it’s clean, safe, and fast – as clean to code in and as type-safe as any modern language, and more than ever the king of "fast."

And the panel (my favorite highlight is at 24:00-28:00):

Lang.NEXT 2012 Expert Panel: Native Languages
Walter Bright, Robert Griesemer, Andrei Alexandrescu, Herb Sutter

Native programming languages panel hosted by Martyn Lovell.

I hope you enjoy them.

I’ve been meaning to post a link to Vincent Lextrait’s nice (and actively maintained) catalog of what languages are used to build what modern and major mainstream software:

The Programming Languages Beacon

This table contains a list of major software products or utilities, with details about the programming languages used to implement them. Information on this is difficult to find, and a few small mistakes might have escaped the author‘s attention. Corrections, suggestions for additions or even references are welcome. …

A nice data point to use to show that the world is built on C++ (and its C subset).

The table was compiled without bias on the part of the person who compiled it; he’s just trying to gather information. If you think a language is under-represented, send mail to Vincent with specific project data (make sure it’s something you know of first-hand or can point to an authoritative source) and I’m sure he’ll be glad to add it.

Nicely put… Christian Lindholm:

Most companies (including web startups), he said, are looking to “wow” with their products, when in reality what they should be looking for is an “‘of course’ reaction from their users.”

Simple and obvious beats flashy. So many great designs are obvious in retrospect.

Hat tip to John Gruber.

Followup on this earlier question, @bilbothegravatar asked:

@Alf, @Herb – I don’t quite get the [[noreturn]] example. While it may (not) compile on VC++, (as far as I understand) it does not carry any semantic meaning, and, what’s more, it is *perfectly* safe for any compiler that sees [[noreturn]] to just ignore it — the runtime behaviour vs. VC++ shouldn’t be changed at all.

So how is [[noreturn]] in the same camp as “restrict” ??? (I agree it may(?) be in the same camp as final and override.)

I will quote Bjarne: (http://www2.research.att.com/~bs/C++0xFAQ.html#attributes)
> There is a reasonable fear that attributes will be used to create language dialects.
> The recommendation is to use attributes to only control things that do not affect the meaning
> of a program but might help detect errors (e.g. [[noreturn]])
> or help optimizers (e.g. [[carries_dependency]]).

Yes, this argument was used. I’m (even) more conservative than Bjarne on this one.

People spoke up for two main different views on the question, “what does it mean to say [[attributes]] should not affect language semantics?” For convenience I’ll label these as the “weak” and “strong” views. Both views agree that if a program is valid both with and without the attribute, it should have exactly the same meaning both ways. Where the two views/camps differ is on whether it counts as “changing the meaning of the program” if a program that is valid if the attribute is ignored is rejected (fails to compile) if the attribute is observed:

• The “weak” view says that’s okay because it didn’t really change the meaning of code that could ever execute, it just caused it to fail to compile. (I know, [[noreturn]] seems like it’s doing that… but it actually doesn’t quite meet this definition in my opinion, see below.)
• The “strong” view, which I strongly support, says that calling a program illegal not only is the most dramatic semantic change possible, but also should be considered a nonconforming extension because it rejects code that is legal in the standard. (I know, [[noreturn]] in particular is standard… but it’s still problematic for this reason, see below.)

On principle, I do not like opening the door to let compiler writers use [[attributes]] as an excuse to not respect legal ISO C++ programs. And I say that as someone who works on a C++ compiler team and actively does C++ language extension design, and having the excuse of disabling part of ISO C++ that I don’t like by throwing in an [[attribute]] could be useful. Don’t get me wrong, there are corner cases of C++ I would like to turn off, but I try hard (and so far successfully) to refrain from doing such a thing without ISO C++’s blessing because it would break source code portability. Encouraging the view that nonstandard [[attributes]] can be a legitimate excuse to reject conforming C++ programs strikes me as putting a live grenade in a public square with a “pull me” tag on the pin. The whole point and primary benefit of having an ISO standard for C++ is to guarantee source portability; this weakens that, and for that reason I view it as a dangerous position to take.

However, in general the “weak” interpretation prevailed, and on those grounds [[noreturn]] and [[carries_dependency]] remained an attribute. I didn’t fight it because at least we got to remove [[final]], [[override]] and [[base_check]] as attributes, which was my primary concern since those would see far more use, and as long as we fixed those I was happy to say I could live with the others in order to get a consensus standard.

Post-Mortem: Assessing [[noreturn]]

Disclaimer: The following is an informational analytical exercise, not a public lobbying for a change. I support where we ended up as a whole to get C++11, it is probably too late to tweak [[noreturn]], and I consciously didn’t pursue making the following arguments at the time because [[noreturn]] (and [[carries_dependency]] are so rarely used that I can live with them, and you have to be willing to give some ground to get a consensus standard – the important thing was to get [[final]], [[override]], and [[base_check]] out and then stop while you’re ahead.

With that disclaimer in place, let me present counterarguments to show why I believe that in an ideal world [[noreturn]] shouldn’t be an attribute because it really is a keyword in [[attributes]] clothing and doesn’t actually meet either the weak or the strong view:

• I don’t think that [[noreturn]] meets the bar set by the weak view, because it does more than just cause programs to fail to compile. In my opinion, adding [[noreturn]] does change the meaning of a conforming program, because the C++11 standard says in 7.6.3/2: “If a function f is called where f was previously declared with the noreturn attribute and f eventually returns, the behavior is undefined. … [Note: Implementations are encouraged to issue a warning if a function marked [[noreturn]] might return. —end note ]” – Even if respecting a [[noreturn]] did cause a compiler to reject some code (which is not required by the standard, and is not even mentioned even in the non-normative note which just talks about maybe issuing a warning), that means that void f(); and [[noreturn]] void f(); do not have the same semantics – returning from the first is always defined behavior (if you do it), and returning from the second is undefined behavior. This isn’t just a language-lawyerly argument either – the reason the standard says “undefined behavior” here is because that’s how the standard explicitly gives latitude to optimizers – it’s saying that “a compiler optimizer may assume the function doesn’t return, and optimize the code in ways that could cause different execution (even catch-fire semantics) if f ever actually does return.” Telling the compiler it may rely on this attribute to have meaning is, to me, clearly giving the attribute a language meaning and so changes the program’s semantics if it is present. So I don’t think it’s actually true that the presence of [[noreturn]] doesn’t affect language semantics.
• It also doesn’t meet the strong view and discourages portability, by opening the door for using nonstandard attributes as a reason to reject conforming code. Now, it’s true that [[noreturn]] is in the standard itself, and so we might be tempted to say it’s not like a nonstandard attribute in this way that reduces portability, but it is – you cannot reliably write portable C++11 code under the assumption that [[noreturn]] has no semantic meaning and can be ignored. That’s because adding [[noreturn]] really does change the meaning of a function declaration (by adding guarantees that the optimizer can use, as described above) and so you really need to treat it as though it were a language keyword – because it is, just dressed in [[attributes]] clothing.

So in my view [[noreturn]] is a keyword dressed in [[attributes]] clothing.

Having said all that, experts do disagree, and the two camps have simply had to agree to disagree on this question – we got unanimous consensus on the standard, even though [[noreturn]] and [[carries_dependency]] are a bit of a sore point, because everyone was satisfied enough that we at least averted having [[final]], [[override]] and [[base_check]].