Edward C++Hands

I dare you to write a full-featured, functional H.264 encoder in Haskell with equal or superior performance. Once such a thing exist I will start believing the hype.

Until then I reserve the right to consider the current Haskell/FP craze the biggest amount of bullshit since the Java/OOP craze.

Sorry people, I already know that magic language/paradigm which solves all problems of software engineering. Which allows me to write 4 times less code, said code being robust and maintainable practically by default, yet as fast as C/C++ if not faster, all that thanks to this great new model of software engineering! It is the (only) future!

Yes, the Java/OOP/design patterns/UML crowd made exactly the same bullshit claims back then. Nobody talks like that about Java/OOP anymore because the bullshit eventually hit the fan known as reality.

Oh and before Sun's viral marketing campaign there were the Lisp weenies. Again, same bullshit. We already have a "30x less code" language which comes bundled with an insufferable sense of intellectual superiority not backed by practical results.

Oh, and I almost forgot the Python/Ruby "dynamic" and "human" craze. "Programming for human beings" - it's the (only) future! Back then the snake oil addicts paraded around dynamic typing and code which read like plain English as the salvation of the programmer. Nowadays they claim dynamic typing is the software engineering equivalent of the Holocaust and that good code must look like math!

I am so tired of it..

Somehow despite the litany of crippling deficiencies, C/C++ have managed to be the foundation of every piece of technology a consumer or a computer professional will ever touch in their daily life. But yeah, other than that, we should all be using.. oh, I don't know, scala or haskell or something like that.

I did try out several other languages and I keep coming back to C++11 for anything that requires scalability and raw performance, like APIs. The same basic server that gets 400 req/sec when implemented in C# ASP.NET achieves 7900 req/sec using C++.

So far I could not find a programming language that does not have similar (or worse) scissors. It's more like "pick your poison" type of choice.

After I learned Scala, my C++ code started to look like functional programming. According to Bartosz that's a good thing, and I did not have to dive into Haskell (yet). :)

"Haskell is not permissive, it won’t let you — or your coworkers — write unsafe code. Yes, initially you’ll be scratching your head trying to implement something in Haskell that you could hack in C++ in 10 minutes. If you’re lucky, and you work for Sean Parent or other exceptional programmer, he will code review your hacks and show you how not to program in C++."

For those who aren't familiar with Parent, watch this talk:

https://www.youtube.com/watch?v=4moyKUHApq4

which introduced me to Stepanov's "Elements of Programming" and the idea that I could be working with better/more reliable/provable abstractions in C++.

That said... after a few weeks of shallowly digesting the material, I started thinking pretty much like Milewski says above: it's great if I can learn to write better C++, but if what I really want is to escape from its specific dangers and general common programming pitfalls, something like Haskell seems like a better bet.

    "There should be one-- and preferably only one --obvious way to do it."

    "C++ is wonderful because there are so many ways to do anything."

Not saying it's a bad language, just sharing my feelings on it.

The 'corrected C++ version of the code' is actually:

std:vector< int > pod( 10 ); ...

I didn't bother reading any further.

That being said, ARC-style reference counting is more limited in terms of what developers can do with their code, and it may not be a general enough solution for a language like C++ (which strives to be all things to all people). Weak pointers in Objective-C also require runtime support, which could probably not be appropriate for high-performance applications in many cases.

It’s worth addressing these in turn. In reverse order:

I dispute that the C paradigm squanders GPUs. OpenCL and CUDA are the two most prominent languages written with GPUs in mind, and both have a lot more in common with C than with Haskell. In particular they eschew functional mainstays like recursion, linked lists, and garbage collection. So for GPUs, it seems like the ideal paradigm is closer to C than Haskell.

For vector units, there’s some recent excitement about auto-vectorization in Haskell. But I’m skeptical about the potential of auto-vectorization in general, since it only seems to apply to simple loops, and can’t take advantage of all instructions. Most effectively vectorized code uses either compiler intrinsics or outright assembly, and I don’t see that changing any time soon (I’d love to be proven wrong on this though).

Lastly, multicore processors. C++11 more or less standardized the creaky POSIX threading model, with some additions like thread locals - hardly state of the art. I wonder if the author is familiar with other approaches, like libdispatch, which provide a much improved model.

One last observation. Parallelism is not a goal! Improved performance is the goal, and parallelism is one mechanism to improved performance. If your Haskell program runs at half the speed of a C++ program, but scales to twice as many cores so as to make the overall time equal, that’s not a wash: it’s a significant win for C++, which did the same thing with half the resources (think battery drain, heat, other processes, etc.) Horse in front of cart.

http://harmful.cat-v.org/software/c++/

I'm sorry and deserve to be downvoted.

http://thread.gmane.org/gmane.comp.version-control.git/57643...

Don't underestimate "instant gratification" even when it comes to programming languages. Yes you might code yourself into a mess further down the line, but most of us are in the business of shipping software not worrying about its correctness.

But of course, this one is an interesting observation: "If nature were as serious about backward compatibility as C++ is, humans would still have tails, gills, flippers, antennae, and external skeletons on top of internal ones — they all made sense at some point in the evolution."

I guess C++ is like Perl: for many things there is more than one way to do a thing; Don't like exceptions? Disable during compilation and code as in C with error codes; That's what makes the whole thing malleable; the right kind of flexibility is a winning feature.

Yeah. But RC is at least deterministic and controllable side. Also, RC is just one of options of C++, while you can implement GC yourself in C++ without any overhead unlike any memory management method on GC.

I love hearing this from OOP insiders. Virtual functions are particularly awful to track down, and are probably worse than GOTO ever was. At least GOTOs only went to one place.

Except it's not. The key is proper encapsulation into classes and generous use of private instance variables.

The real problem is social: people want to get something done quickly, so instead of talking to the original author[1], they put a new method in the class (or declare a friend) and happily continue hacking, without thinking of far-reaching consequences of whether unrestricted (that's what public is) use of the newly introduced method violates class invariants in some way.

[1] I'm aware that the original author might not be there anymore. Which makes a good case for documenting design and intent of the code. A QA matter.

How does Haskell solve the social problem (directly hacking something into a module you don't own or fully understand)?

> What you don’t realize is that it will take you 10 years, if you’re lucky, to discover the “right way” of programming in C++

IMO, only novices and beginners look for "THE right way". Advanced people realize that the "right" way depends on the broad context and look for (the) best compromise solution among a spectrum of solutions.

I believe this holds for other computing-related things (designing a LAN, database tables, etc.), as well as real life (sports, martial arts, even everyday things like sitting and walking as any person who has had a lower back problem will tell you).

The problem is again social: novices and beginners who refuse to "grow up" and who know just enough to be dangerous: they can produce working but messy code, and refuse to learn other ways of doing the same thing in an appropriate context. (E.g. when to use while vs for, or why copy-pasting large chunks of code between different functions is generally "bad".)

Somehow I'm not convinced that Haskell is the magic bullet which solves the underlying social/human issues.

> Haskell is not permissive, it won’t let you — or your coworkers — write unsafe code.

He never defines what "unsafe" is. Mutation is not unsafe per se.

> Don’t be fooled: accessing atomic variables is expensive.

I've seen recent slides where the measured cost of an uncontended locked cmpxchg on Haswell was ~20 cycles vs ~5 cycles unlocked. This is NOT expensive, unless unnecessarily you replace all memory accesses with their atomic equivalents.

> Most importantly though, threads are not a good abstraction for parallel programming

No, but they are an essential building block.

> Haskell is way ahead of the curve with respect to parallelism

First, a computation can be abstraceted into a data dependency graph.

Now, the reason that most of today's applications don't benefit a lot from the vast number of processors available is not that the underlying programming is somehow unsuited for parallelism. It is because that there IS NO parallelism available in these applications: data dependency graph is mostly serial, and if parallelism is available, it is on such a small scale that superscalar CPUs already make use of the large part of it. Also, with overly fine-grained parallelism you WILL end up in a situation where the overhead of atomic operations becomes non-negligible, even if it is only ~20 cycles.

I believe that if people more often thought about their designs in message-passing terms, the dependency graph would also emerge, and they would see that there often is very little parallelism to extract through explicit parallelization. (Note that writing to a shared variable is just an extremely simple and efficient method of sending a message).

This was also remarked on by Knuth: During the past 50 years, I’ve written well over a thousand programs, many of which have substantial size. I can’t think of even five of those programs that would have been enhanced noticeably by parallelism or multithreading. [http://www.informit.com/articles/article.aspx?p=1193856]

So, IMO, easier coding for shared-memory parallelism is one of the worst reasons to switch programming languages.

That's why I personally prefer Erlang-style concurrency (actors). Communication patterns and parallelism granularity is explicit, and communication cannot be decoupled from synchronization. [With shared variables, these two are decoupled.]

The sad situation is we have no worthy competitor. Go?

Anyway, here is a question about C++. Last week I tried to implement a parser for a subset of CSV - one-byte-per-character, fields separated by comma, no quoting, fixed line ending. The only requirement was speed. So I started with a simple C++-style implementation, read one line at a time with std::getline, split with boost tokenizer, copy into vector of vector of string. But it was too slow, so I reimplemented it C-style - boom, first try, 30 times faster. Through some micro-optimisations I got it 30% faster still - copying less, adding some const left and right, caching a pointer. So if anyone is so inclined, how would I make the following more C++-ish and still get the same speed? Using fopen and raw char* to iterate over the memory buffer are what I'd consider the non-C++ aspects of it, but feel free to point out other idiom violations...

    bool CsvParser::OpenCStyle(boost::filesystem::path path)
    {
      FILE* fh = NULL;
      ::fopen_s(&fh, path.string().c_str(), "rb");
      if (fh == NULL) {
        return false;
      }

      const int BUFSIZE = 1024 * 256;
      char buf[BUFSIZE];

      m_Records.reserve(m_EstimatedRecordCount);
      bool at_end_of_file = false;
      std::string carryover_field_data;

      std::vector<std::string>* current_line = NULL;
      bool at_new_line = true;

      const char separator = m_Separator;

      while (!feof(fh)) {
        size_t size_read = ::fread(buf, sizeof(char), BUFSIZE, fh);
        char* start_of_field = buf;
        size_t i = 0;
        for (i = 0 ; i < BUFSIZE && i < size_read ; i++) {
          if (at_new_line) {
            m_Records.push_back(std::vector<std::string>());
            current_line = &m_Records.back();
            at_new_line = false;
          }
          if (buf[i] == separator || (at_new_line = (buf[i] == '\n'))) {
            current_line->push_back(std::string());
            if (carryover_field_data.size() != 0) {
              std::string field(start_of_field, &buf[i] - start_of_field);
              m_Records.back().push_back(carryover_field_data + field);
              carryover_field_data = "";
            } else {
              current_line->back().assign(start_of_field, &buf[i] - start_of_field);
            }
            start_of_field = &buf[i + 1];
          }
        }
        carryover_field_data = std::string(start_of_field, &buf[i] - start_of_field);
      }

      fclose(fh);

      return true;
    }

We would all love programming to be easier, for the compiler or interpreter to just know what we really meant, rather than what we actually typed, but sometimes the tools are sharp, are a bit more manual, exactly because they offer more control.

The constant sell of Haskell or Go as the panacea for all programming problems is like someone else telling us all to adopt socks made of rubber - a few make like that, may even blog and evangelise about it, but the rest of us find it uncomfortable and annoying.

There comes a time when no one uses a feature anymore so it might as well be dropped. How many of you still have floppies on your computer?