Live data from Hacker News

Zed Shaw on C++

librelist.com

161–170 of 210 posts

Re: Zed Shaw on C++

#161
post #73

Earlier quoted context omitted.

There's this thing called a joke . . . I believe that's waht Zed is making here.

You Sir, win a dollar! I think to make the joke really clear I'd have to add a few more consts and some pointers in there.

No, that's just what you'd need to make it compile

Re: Zed Shaw on C++

#162

I'm going to keep saying this until I turn blue in the face. Perhaps if I stamp my feet it might get more attention (wink) Please stop confusing the language with the APIs or the available libraries and features of the language. This sounds simple, but it's profound: simply because you can do something, that doesn't mean that you have to do it that way. To use Zed's example, let's say I'm hacking around a lot of stri…

"is there a reason to make a class and wrap some things? If so, you can do that in C++. You can't in C."

Yes, you can. Object orientation is a property of the program, not the programming language. Pretty much every time I crack open C now, I'm writing Object-Oriented C.

(Also, immutability is a property of the program, not the programming language. Etc.)

Re: Zed Shaw on C++

#163

Earlier quoted context omitted.

Lots and lots of things are bad in C++. But that's because it's an elaborate language with lots of things in it. You only have to use one bad thing at a time ;-). Basically, any language with lots of modularity and lots of low level access is going to be big and have lots of features that are problematic in some situations.

Say you need both modularity and low level access in a given program. Can they be so entangled that you absolutely have to put both in the same language ? No matter how I put it, I fail to see how C++ can be better than C + (Python or Lua or Haskell, with FFI). Is the concept of using 2 languages at the same time so scary?

| Is the concept of using 2 languages at the same time so | scary?

Yes, but it seems to be inevitable. Python + C. Haskell + C would be my choices for large scale modeling/data analysis. For apps involving a GUI, I would like to hear others thoughts.

Re: Zed Shaw on C++

#164
post #11

Earlier quoted context omitted.

The best pro C++ argument is that for all its flaws there's nothing out there that completely replaces it and it's still widely used. My own view: I'm not in love with C++, but it's not nearly as bad as everyone makes it out to be. Most of the arguments I hear against C++ are the same tired things I've heard hundreds of times. They all have a grain of truth, but nothing so bad as to condemn the language.

My short rant: C++ is as bad as they say it is. It is horrible, it is the worst language in the world ... except for all the other (a la Winston Churchill and democracy). The horrifical complexifications of C++ are just terrible, yet every one of them has a reason behind it. And also, the horrifical complexities are a bit more optional than the horrifical complexities of, say, Java. There isn't another language that…

What you say about Java's verbosity is sort of flawed in the same way that attacks on C++ about its template metaprogramming madness are flawed. Don't confuse a language with what people write in it.

There is a point though. C++ encourages obscure "too clever" constructs, and Java encourages excessive verbosity. But in both cases you can decide not to go there.

Re: Zed Shaw on C++

#165
post #155

Earlier quoted context omitted.

The C++ standard library and std::string implicitly have specific constraints and use cases, but they were imposed by the design process, not by the language. C++ has many string types because each string type has its strengths and weaknesses. For instance, QString is a fully-featured and Unicode-aware string written in C++ that I use most of the time. std::string is good for most things. What are your specific issue…

I don't write C++ and have no issue with std::string. I was taking general issue with the OP's general issue with criticizing a std library alongside a language.

[deleted]

Re: Zed Shaw on C++

#166

I'm going to keep saying this until I turn blue in the face. Perhaps if I stamp my feet it might get more attention (wink) Please stop confusing the language with the APIs or the available libraries and features of the language. This sounds simple, but it's profound: simply because you can do something, that doesn't mean that you have to do it that way. To use Zed's example, let's say I'm hacking around a lot of stri…

mentally replace "language" with "language environment" and all will make sense to you; it will also put you in line with how most people read this discussion.

You: language = base syntax + semantics Most: language = base syntax + semantics + common idioms + standard library + popular libraries

Re: Zed Shaw on C++

#167
post #33

I agree totally with Zed Shaw on this, but some quick observations: * C++ circa 2000 (before mainline g++ could handle Alexandrescuisms) is significantly different from C++ circa 2010, albeit in ways that probably upset Shaw even more (the more central role boost has taken, the more "expressive" templates have gotten, don't call me on any of this stuff). * C++ std::string is an abomination, but you can always just do…

> const-correctness may be another misfeature (I know I make fun of it), but the point isn't hard to see: if you take the time to const-correct your code, the compiler will spit out errors that would have otherwise been runtime faults. I think it is so interesting the mentality of static typing people. I would much prefer handling the few resulting run time faults than having to stuff with my code with const. Anyway,…

I think it's interesting the mentality of dynamic typing die-hards. I find it much easier (for complex projects) to just type "const" where appropriate and let the compiler think about mutability for me, than to think about mutability myself. The mental overhead is definitely superlinear with the complexity of the project, and typing "const" a few times lets me use that resource for more subtle correctness issues.

Of course, one problem with C++ (and, to a lesser extent, C) is that many of those subtle correctness issues are direct results of the type system in the first place. Go figure.

Re: Zed Shaw on C++

#168
post #11

Earlier quoted context omitted.

The best pro C++ argument is that for all its flaws there's nothing out there that completely replaces it and it's still widely used. My own view: I'm not in love with C++, but it's not nearly as bad as everyone makes it out to be. Most of the arguments I hear against C++ are the same tired things I've heard hundreds of times. They all have a grain of truth, but nothing so bad as to condemn the language.

My short rant: C++ is as bad as they say it is. It is horrible, it is the worst language in the world ... except for all the other (a la Winston Churchill and democracy). The horrifical complexifications of C++ are just terrible, yet every one of them has a reason behind it. And also, the horrifical complexities are a bit more optional than the horrifical complexities of, say, Java. There isn't another language that…

> The horrifical complexifications of C++ are just terrible, yet every one of them has a reason behind it.

Many of the reasons are legacy issues though like using dumb linkers and using the C preprocessor rather than a real module system. Templates are just a huge hack: manipulating the text of the source code to simulate generics and then abusing that feature to get meta programming.

One of the great mysteries of life is why there isn't another language that "has both the large-scale modularization given by OO and low-level efficiency of direct pointer manipulation and other C features" yet doesn't make the same mistakes as C++.

Re: Zed Shaw on C++

#169
post #57

Earlier quoted context omitted.

The problem with std::string is that when I type a quoted string in my code, it isn't natively a std::string, it's natively a char* and gets converted to strings. C++'s biggest mistake was not standardizing early on an official object-oriented string datatype. It should have been in the first version of C++, it should have been treated like a primitive type (even if it isn't), and they should have said "thou shalt us…

The great thing about const is that if you don't like it you can pretty much ignore it. The only time it might be necessary to deal with it is if you are using a library that returns const objects. If you do like const (which I do) then you can put it in pretty much everywhere, except if you are dealing with a library that isn't "const correct", but then a bit of type casting will save the day. That's a big advantage…

"If you do like const (which I do) then you can put it in pretty much everywhere"

In retrospect, it might have been better to have a keyword for things that can change. This goes equally for Java and "final". Making immutability the default and mutability opt-in makes for fewer bugs and more reliable programs.

Arguably, this is what Clojure does where you have functional, immutable constructs by default with ways to declare things that can change (refs, etc.).

Re: Zed Shaw on C++

#170
The std::string example given by Zed shows that he didn't hack around C++/STL much.

There is a whole entry in Exceptional C++ Style (or another Herb's book) that says how much std::string sucks and how you can write an equivalent extremely quickly.

Anyway, don't like std::string ? You can use std::vector in place very easily, that's a well known trick (thanks to the guarantee that &v[0] returns a pointer to the data if v is a vector).

He talks about references but he seems to ignore the capability of C++ to offer perfect forwarding which enables you to greatly increase performance and memory usage and that's very difficult to mimic in pure C.

There's a lot to write about inaccuracies in this post actually, but what the point? People who hate C++ will discard them and people who love it already know it.

I tire of reading posts from people who didn't like a language for whatever reason and try to rationalize it.

Post reply on HN