Herb Sutter: Elements of Modern C++ Style

The always readable Herb Sutter begins Elements of Modern C++ Style with:

The C++11 standard offers many useful new features. This page focuses specifically and only on those features that make C++11 really feel like a new language compared to C++98, because:

• They change the styles and idioms you’ll use when writing C++ code, often including the way you’ll design C++ libraries. For example, you’ll see more smart pointer parameters and return values, and functions that return big objects by value.
• They will be used so pervasively that you’ll probably see them in most code examples. For example, virtually every five-line modern C++ code example will say “auto” somewhere.

Use the other great C++11 features too. But get used to these ones first, because these are the pervasive ones that show why C++11 code is clean, safe, and fast – just as clean and safe as code written in any other modern mainstream language, and with C++’s traditional to-the-metal performance as strong as ever.

This sounds good.

Focus, focus, focus

Steve Jobs, role-model for Google CEO.

The 300

A collation of the top 300 algorithms. Please contribute implementations.

Why does blogger republish my posts so often?

Watching the ThoughtWorks Alumni aggregator feed, I see my own posts reappear frequently in batches. I'll see posts last edited days ago suddenly repost. Any suggestion on stopping this misbehavior would be appreciated.

Cheers,
--binkley

When it rains, it pours

More on one of my favorite themes: Romain Prieto provides Expressive code: combining Guava, LambdaJ and Hamcrest.

Kotlin and delegation

I have harped on Java for some time to add language support for delegation. Well, Java is not headed that direction anytime soon. But Kotlin delivers!

Saying:

class Derived(b : Base) : Base by b

forwards method calls on "Derived" to "Base" through the instance of Base named "b". Nifty!.

Kotlin is so full of good ideas it's hard to know where to start.

Neal Ford on functional programming

ThoughtWork's Neal Ford posts a great discussion of object-oriented vs. functional style for coupling and composition. Functional is where it's at. Read Neal to see why.

Amazon and SOA

Steve Yegge's rant really describes how to make SOA work at full-on scales. This is pure gold:

[M]onitoring and QA are the same thing. You'd never think so until you try doing a big SOA. But when your service says "oh yes, I'm fine", it may well be the case that the only thing still functioning in the server is the little component that knows how to say "I'm fine, roger roger, over and out" in a cheery droid voice. In order to tell whether the service is actually responding, you have to make individual calls. The problem continues recursively until your monitoring is doing comprehensive semantics checking of your entire range of services and data, at which point it's indistinguishable from automated QA. So they're a continuum.

Memory for nothing and chips for free

As a long time Linux user, this quote from MSDN nearly spilled my coffee (emphasis mine):

Fundamentals such as memory usage represent a key engineering tenet of Windows 8. In building Windows 8 we set out to significantly reduce the overall runtime memory requirements of the core system. This is always good for everyone and especially in a world where people want to run more and more apps at the same time or run on systems with only 1 or 2GB of memory.

I'm happy to read this post and see engineering has a seat at the table for Windows 8. Funny world where memory is next to free.

If you say "world's best", you should be right

Peteris Krumins publishes the World's best introduction to sed. And he's right.

The power of laziness

On the power of laziness from Australian CIO Magazine:

'Progress isn't made by early risers. It's made by lazy men trying to find easier ways to do something.' Robert Heinlein (1907-1988)

And Seth lived a hundred and five years, and begat Enos

Well, Java has not been around 105 years, but it feels like that sometimes.

David Polak explains why Scala is too hard to replace Java. I laughed at this true description of JEE programming:

Junior developers who are asked to maintain code written by senior developers have to understand the idioms and patterns in the code. While Scala makes putting business logic at the forefront of the code (rather than distributed through a bunch of for loops and complex if statements), depending on the idioms used, decoding that logic is non-obvious. This is a variant of the lack of idioms issue, but at the end of the day, you need a team with a mind-meld to grok some Scala code. … In Java, the patterns are vomited out of the IDE, so developers grow up being able to spot the patterns. That's not true of Scala where the idioms are diverse and team/framework specific.

How to know if Scala is right for you?

• Your company has speakers at JavaOne, OSCON, Strangle Loop, QCon: Scala will be easy
• Lunch-time discussions involve the criteria for moving from a developer to a senior developer: Scala will be hard
• Your developers can write code in NotePad if they have to: Easy
• Your developers stare blankly or say 3 "Hail Marys" when they hear the name "Zed Shaw": Scala == Hard
• Developers all follow Dean Wampler on Twitter: Scala Easy
• Your developers come in at 9:15 and leave before 6 and don't check work email at night: Hard

Given Dave's solid criteria in the posting, my organization will find Scala hard to adopt. I am saddened, because Scala looks fun, productive and intelligent. But my foremost job is to help my organization succeed.

Which brings me to Kotlin (emphasis in the original):

"Project Kotlin" is the codename for a statically-typed JVM-targeted programming language developed by JetBrains and intended for industrial use.

On the Java to Scala scale Kotlin lies solidly between, more like Java in some areas, more like Scala in others, unlike either in yet others. Overall Kotlin looks like a winner for organizations looking to bail from Java but find Scala and friends daunting.

Kotlin may prove a winner.

Architecture gone wild

Tony Arcieri rants on bad suggestions from Node.js folks. His catch phrase, "It gets worse". I love his conclusion:

Clearly the next logical steps are to store previously computed Fibonacci numbers in MongoDB. Or you could build a system with Socket.IO which caches previously computed Fibonacci numbers client-side using a distributed hash table. Then you'd be well on your way to a multimillion dollar cloud-based Fibonacci number service. Eventually you'll probably want to build in an OpenMP C++ native extension to calculate Fibonacci numbers across multiple CPU cores. That way you'll have a truly roflscale Fibonacci web service.

I run into this kind of thinking occassionally at work, but it is quickly tamped down before real money gets burned.

OCaml in real life

Yaron Minsky of the quant prop shop, Jane Street, promotes OCaml in the ACM Queue with OCaml for the Masses. His writing is exact, his code example illuminating and short.

JetBrains IntelliJ IDEA on github

Cool beans: IntelliJ IDEA Community Edition now on GitHub.

Dream on

Big words from Oracle:

Looking ahead to Java 9 and beyond, he explained, Oracle is already identifying key areas of development: a self-tuning JVM, improved native integration and big-data support, reification, adding tail calls and continuations, a new meta-object protocol to improve cross language support, multi-tenancy, resource management for cloud applications, and the building of heterogeneous compute models.

If they deliever this will help poor Java. 60s & 70s technologies 30 years later is better than a poke in the eye with a sharp stick.