Posts Tagged ‘Java’

Regime Change

November 12, 2014 4 comments

Revolution is glamorous and jolting; evolution is mundane and plodding. Nevertheless, evolution is sticky and long-lived whereas revolution is slippery and fleeting.

As the figure below from Neal Ford’s OSCON “Functional Thinking” talk reveals, it took a glacial 16 years for Object-Oriented Programming (OOP) to firmly supplant Procedural Programming (PP) as the mainstream programming style of choice. There was no revolution.

Starting with, arguably, the first OOP language, Simula, the subsequent appearance of Smalltalk nudged the acceptance of OOP forward. The inclusion of object-oriented features in C++ further accelerated the adoption of OOP. Finally, the emergence of Java in the late 90’s firmly dislodged PP from the throne in an evolutionary change of regime.

I suspect that the main reason behind the dethroning of PP was the ability of OOP to more gracefully accommodate the increasing complexity of software systems through the partitioning and encapsulation of state.

Proc to OO

Mr. Ford asserts, and I tend to agree with him, that functional programming is on track to inherit the throne and relegate OOP to the bench – right next to PP. The main force responsible for the ascent of FP is the proliferation of multicore processors. PP scatters state, OOP encapsulates state, and FP eschews state. Thus, the FP approach maps more naturally onto independently running cores – minimizing the need for performance-killing synchronization points where one or more cores wait for a peer core to finish accessing shared memory.

regime change

The mainstream-ization of FP can easily be seen by the inclusion of functional features into C++ (lambdas, tasks, futures) and the former bastion of pure OOP, Java (parallel streams). Rather than cede the throne to pure functional languages like the venerable Erlang, these older heavyweights are joining the community of the future. Bow to the king, long live the king.

Categories: C++ Tags: , , ,

Live Instructor, Or Live Code?

September 25, 2014 Leave a comment

I’m currently taking an in-house course on Java programming. The material is being presented in standard lecture fashion where the instructor sequentially walks through a series of static powerpoint slides and explains what the code snippets on each slide are doing.

In parallel to the in-house class, I’m also taking an online Java video course taught by Paul Deitel in the comfort of my home. The 36 hour course is available to me through my pricey (but outstanding) safaribooksonline subscription:


Other than in the lesson video intros (e.g. the one above), you never see Mr. Deitel on the screen. Like many educational videos you can watch for free on YouTube and Kahn Academy,  you see code and a yellow circle highlighter that Paul dynamically steers around  the screen as he explains what the code is doing.

live code

Even though the standard “live instructor” teaching method enables the student to ask a physically-present instructor questions in real-time, I find the video “live code” method much more flexible and effective for the following reasons:

  • You can see the instructor dynamically interacting with the IDE (in this case Eclipse).
  • You can learn at your own speed by replaying lesson snippets that you didn’t fully grasp the first time. (I’m not so smart, so I use this feature all the time).
  • The instructor can compile/run the code in front of your eyes and connect the code with its output by switching between the console and the code editor as needed.
  • The instructor can intentionally insert bugs in the code and step through the debugger.
  • The instructor can switch between the code and detailed online documentation as needed.

Regarding this particular course, I’m thrilled with Mr. Deitel’s work. He’s very thorough, shows great empathy for the student, and he dispassionately points out the differences between Java and C++ as they emerge throughout his code examples.

As I learn more details about Java, I’m confirming what everybody has been saying about the language since its inception: it is a smoother and easier to learn language than C++. However, I (still) don’t like:

  • Centralized garbage collection (I prefer C++’s RAII idiom and smart pointers for localized garbage collection).
  • The fact that all methods are virtual by default.
  • The fact that every user-defined reference type inherits from class Object.
  • The fact that a whole other layer of software, the JVM, sits between user code and the operating system.
  • The fact that Java” steers” programmers toward designing deep, complicated inheritance hierarchies regardless of whether that style fits the application.

Regarding the last point, the mental steerage toward a pure OO programming style is subliminally catalyzed in the way that the JDK library packages are designed and the proliferation of large frameworks in the Java community.  The obsession with deep hierarchies reminds me of Microsoft’s horrendously complicated old MFC framework for writing Windows GUI applications.

I’ve personally seen the effects of a fixed OO mindset in Java programmers who subsequently learn and write C++ production code in my domain: distributed real-time event systems that are naturally “flat“. The code ends up being overly complicated, hard to understand, and very few methods in the deep trees end up being called. The end result is that the “smoothness” of the language is nullified, developer time is wasted on unnecessary code, and the code is hard to maintain.


Categories: technical Tags: ,

Two Opposing Ideas

October 3, 2013 1 comment

If you didn’t already know it, I’m a fan of the C++ programming language. Of course, not everybody feels the same way. There are many smart people who are among the “haters“.

C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. – Linus Torvalds

When I read anti-C++ tirades like Linus Torvalds’ emotionally charged attack, it always stings a little at first. But then I eventually step back from the “emotional-me” and remember (thanks to the teachings of Byron Katie and Eckart Tolle) that the world will never be the way I “demand!” it to be. The length of time it takes me to disengage from abstract thought-storms like these and return to earth is proportional to how deeply I’m attached to one side of the debate stomping around in my head.

“The test of a first-rate intelligence is the ability to hold two opposing ideas in mind at the same time and still retain the ability to function.” – F. Scott Fitzgerald

Java  creator James Gosling, Haskell‘s Bartosz Milewski, and Go creator Rob Pike are three of the more prominent people in the anti-C++ camp.  As expected, they have agendas to promote: advocating their own favorite programming languages at the expense of C++.

Ironically, these rants by smart and well known people can be construed as tributes to C++. That’s probably why this is one of my favorite Bjarne Stroustrup quotes:

There are just two kinds of languages: the ones everybody complains about and the ones nobody use.

Cpp Siege

Great, But Weird And Slow

August 31, 2012 Leave a comment

Damien Katz is the soft-spoken Couchbase CTO and creator of the Apache CouchDB (written in Erlang and C/C++). In this InfoQ presentation, “Erlang, the Language from the Future?“, Damien praises the Erlang programming language. But he also points out its turds: weirdness and slowness.

Damien says that Erlang’s weird Prolog-like syntax prevents massive adoption; which prevents lack of massive investment; which prevents massive VM performance improvement.

To prove his point, Mr. Katz uses Java as an example of “getting it right“. When Java arrived on the scene in the mid-90’s, it was dirt slow compared to C and C++. But because Java’s syntax was C-like and it didn’t suffer from the frustrating quirks and gotchas of C/C++, it was embraced quickly and massively by the software industry. This lead to massive investment, which lead to large JVM performance increases and a boatload of productivity-enhancing development tools.

I like Erlang a lot for the concurrent, distributed type of software I write. However, Damian hits the nail right on the head. What do you think?

Best Actor Award

I recently watched (Trifork CTO and Erjang developer) Kresten Krab Thorup give this terrific talk: “Erlang, The Road Movie“.  In his presentation, Kresten suggested that the 20+ year reign of the “objectsprogramming paradigm is sloooowly yielding to the next big problem-solving paradigm: autonomous “actors“. Using Thomas Kuhn‘s well known paradigm-change framework, he presented this slide (which was slightly augmented by BD00):

Kresten opined that the internet catapulted Java to the top of the server-side programming world in the 90s. However, the new problems posed by multi-core, cloud computing, and the increasing need for scalability and fault-tolerance will displace OOP/Java with actor-based languages like Erlang. Erlang has the upper-hand because it’s been evolved and battle-tested for over 20 years. It’s patiently waiting in the wings.

The slide below implies that the methods of OOP-based languages designed to handle post-2000 concurrency and scalability problems are rickety graft-ons; whereas the features and behaviors required to wrestle them into submission are seamlessly baked-in to Erlang’s core and/or its OTP library.

So, what do you think? Is Mr. Thorup’s vision for the future direction of programming correct? Is the paradigm shift underway? If not, what will displace the “object” mindset in the future. Surely, something will, no?

Too much of my Java programs are boilerplate code. – Kresten Krab Thorup

Too much of my C++ code is boilerplate code. – Bulldozer00

Java either steps up, or something else will. – Cameron Purdy

New Native Languages

The editor of Dr. Dobb’s Journal, Andrew Binstock, has put together a nice little slideshow summary of four “modern” native (native = no virtual machine running underneath the code) programming languages here: New Native Languages. As the figure below shows, these relatively new languages are D, Go, Vala, and Rust.

According to Andy, “older” native languages like C11 and C++11 “can have the feel of a past era onto which contemporary elements have been grafted“. I don’t agree with his “grafted” assertion, but I have to begrudgingly agree with him when he says:

The upshot is that to be truly expert in C++ requires far more education and far more effort than comparable mainstream OO languages (notably, Java and C#). – Andrew Binstock

Relentless Assault

May 9, 2012 2 comments

Microsoft’s Herb Sutter is a whirling dervish. Since the ISO approval of the C++11 standard last fall, he’s been on a crusade to promote C++ via several comparative assaults on Java and Microsoft’s own C#.

Herb’s latest blitzkrieg occurred at the 2012 conference (video link, slides link). In this slide, Herb summarizes some of the C++11 features that close the productivity and safety gap relative to C# and Java.

In this next slide, Herb contrasts C++11’s adherence to its more open “trust the programmer” philosophy against the more closed “we know what’s good for you” C#/Java philosophy.

Unless the large movement of business applications to the cloud is the latest fad du jour, the following two slides show that the largest software development and maintenance costs will shift from labor to compute efficiency. Thus, it doesn’t matter how programmer friendly your language is and how low the salaries you pay are, you might find that your costs are going up because of power drain in massive data centers and time spent frantically optimizing VM-based code that’s relatively slower and bigger.

In closing, Herb, the nice guy that he is, backs off a bit with this “the right tool for the right job” slide:

Is Herb stretching the truth and exaggerating the improvements offered up by C++11? The fact that I wrote this post obviously means that I don’t. What about you, dear reader? What say you?

Different Goals And Unfair Comparisons

October 13, 2011 Leave a comment

At the behest of a work colleague, I revisited the Java programming language. I re-read James Gosling‘s 1995 white paper that introduced the language and I perused several Java-related wikipedia articles. Using those sources and Bjarne Stroustrup‘s “Evolving a language in and for the real world: C++ 1991-2006” paper, I developed the following side by side “design goals” lists:

In spite of these radically different design goals, people (including myself) continue to insist on comparing the languages in passionately irrational ways. If both language designs were driven by a common set of goals, then objectively valid comparisons could be made.

Java was intentionally designed from a blank sheet; unfettered from the ground up. Au contraire, C++ was intentionally designed by extending C and attempting to fix it’s short comings without breaking millions of lines of deployed code. It’s like comparing apples to oranges, dontcha think?

Categories: C++ Tags: , , , ,

Biased Comparison

September 16, 2011 Leave a comment

Let me preface this post by saying what lots of level-headed people (rightly) say: “choose the right tool for the right job“. Ok, having said that, take a quick glance again at the first word in this post’s title, and then let’s move on….

Take a look at the diagram below in terms of flexibility and performance. C++ provides developers with several programming style choices to solve the problem at hand and Java (Smalltalk, Eiffel) “handcuffs” programmers with no choice (in BD00’s twisted mind, Java Generics are clumsy and they destroy the OO purity of Java, and thus, don’t count).

Regarding program performance (<- ya gotta check this interactive site out), there’s “virtually” no way that a Java program running on top of an overhead “middleman” virtual machine can be faster than native code running on the same CPU hardware. Of course, there can be the rare exception where a crappy C++ compiler is pitted against a highly optimized (and over-hyped), “JIT” Java compiler .

Nevertheless, a price has to be paid for increased power and flexibility. And that price is complexity. The “learnability” of C++ is way more time consuming than Java. In addition, although it’s easy to create abominations in any language, it’s far easier to “blow your leg off” using C++ than using Java (or just about any other language except assembler).

Having spewed all this chit, I’d like to return to the quote in this post’s first paragraph: “choose the right tool for the right job“. Seriously consider using C++ for jobs like device drivers, embedded real-time systems, operating systems, virtual machines, and other code that needs to use hardware directly. Use Java, or even simpler languages, for web sites and enterprise IT systems.

The main weakness of OOP is that too many people try to force too many problems into a hierarchical mould. Not every program should be object-oriented. As alternatives, consider plain classes, generic programming, and free-standing functions (as in math, C, and Fortran). – Bjarne Stroustrup

Unneeded And Unuseful

July 8, 2011 3 comments

On Bjarne Stroustrup’s C++ Style and Technique FAQ web page, he answers the question of why C++ doesn’t have a “universal” Object class from which all user-defined C++ classes automatically inherit from:

I felt the need to post this here because I’m really tired of hearing Java programmers using the “lack of a universal Object class” as one reason to stake the claim that their language of choice is superior to C++. Of course, there are many other reasons in their arsenal that undoubtedly show the superiority of Java over C++.

%d bloggers like this: