Henry One of my sore points.
It's a tribute to mankind's collective ability to self-deceive that the damn language has taken such a hold. I similarly let rip on Quora recently (pasted below, far too long, but might amuse). You are not alone, but you may not have not felt the true pain of C++ yet. The STL and Boost make Malbolge seem quite enticing as an alternative. Jo. [talking about Java and C++] I find that I have to be meticulous in avoiding error as the languages seem to invite me to fail, but possibly this is just my bad habits. I find huge inconsistencies in the way similar things work, and copious documentation that tells me everything but the stuff I need to know (Thank Darwin for StackExchange!) I find code that burgeons and burgeons. I find myself taking a week to tediously debug something that should have taken a couple of hours. But perhaps this is because I haven't thrown my heart and soul into C++ or Java. Likely it's just me, but let's talk about C++. A tiny example. Let's say you want to simply read in a file, line by line, perhaps make some amendments, and as you make them, write an amended file to an ofstream. Let's also say that you want to trap errors, testing for the various failure conditions, and that you want your code to work consistently across a variety of platforms, say Windows and Linux. Soo, we think "Just to start off I'll be a good little programmer and pop the relevant code in a try/catch statement." We specify exceptions for the ifstream and the ofstream. Hmm, first thing we discover is that we can't separately catch the ofstream and the ifstream. So we need some sort of little hack to distinguish between the two. Now, how do we test the flags that say what happened? You'd think we could just mask an integer that might, just might be conveniently available, but no, we seem to have to deploy a whole lot of different little methods, one for each flag. And *then* we discover that---woops---once the EOF condition is met, one of the other damn error flags is also set. The stream has run dry. So we disable these flags on the ifstream to get things working. But then of course it's a good idea to trap any other badness that might happen---Sigh, another catch statement--- but because we don't want to say catch(...) except in desperation, we have to say something like "catch(const std::exception &e)", and leave the desperate "catch(...)" for last. And then we realise that if we want a meaningful error message, we have to indulge in a whole lot of other rather arbitrary hacks. And *then*---just as we've bitten our lips into bloodiness---we get our simple program working, only to discover that somewhere along the line, because we're working in Windows, some friendly "feature" has altered all of the \r\n newlines to \r\r\n. Aagh. But maybe that's all my fault. Try this in Python. Try writing thirty lines of obscure code in C++ and then reducing it to two lines of J. Juxtapose regex and a C++ representation of the same functionality. Try spawning 100,000 concurrent processes in C++ ... wooops ... and then do the same in Erlang. If you've ever built your own Turing machines and compared what they can do with what functional languages can do, you'll realise that all languages are not created equal. You might also come to the realisation that, although immensely popular, C++ and Java might just belong at the bottom of the heap, so quibbling about minor differences between these two languages is arguably more of a waste of time than reading the above rant!" On 6 September 2015 at 03:05, Henry Rich <[email protected]> wrote: > Yesterday I had to do something I have so far avoided my entire > programming career: use the features of C++. [I kept my head when all > around me were losing theirs on Smalltalk; I took the same approach with > C++ but I was finally run to ground]. > > I needed the C++ equivalent of a list of boxed strings. Can't be so hard, > right, with all those classes, templates, objects, whatnot? I found some > code that had a list of strings, and used it. Failure. > > It turns out that "string" means different things to different people: > some think it's just an array of characters (char[]), while others think > it's a null-terminated memory area pointed to by a (char *). The class I > was using expected null-termination, and my strings contained nulls, so > assigning a = b; set b equal to a, but only up to a point. > > It took me about an hour to figure out that the problem was the meaning of > "string", which is unambiguously defined in many places, but with > conflicting definitions. Then another half-hour to work out that what I > wanted was (list<string>) because (list<char[]>) isn't supported. Then 10 > minutes to solve the problem. > > I ended up with the thought that documentation is hard to read whenever > the topic is unfamiliar. I'm just saying. > > Henry Rich > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
