Hacker News Reader

Comment by coliveira | Hacker News Reader

> It's okay for functions to have unknown behavior that I have to learn about before using them, because I'm used to that, but it's not okay for types to have any kind of unknown behavior, because I'm used to C,

It is not an issue of behavior but of understanding.

In C++, a large number of things can be happening in a single line: an operator being called, a type conversion, a template instantiation, an overriden function in one of a dozen of classes, a constructor called in some part of the hierarchy, in some namespace... who knows. You have to be smart enough to figure out what is going on in each of these cases. As you code base grows, this makes it increasingly hard to understand what is going on.

View on HN

By that logic, you shouldn't use any dynamic language, because someone could monkey-patch every function and you'd have no guarantee what exactly was being called.

Also, you forgot macros in your list of gripes, as they can stomp on literally ANYTHING indiscriminately, despite being declared far away from the actual invocation point.

A friend of mine actually encountered #define FALSE 1 in some header file he included from a 3rd party project. It was straight C.

I'm not sure why after finding that he decided to file a bug report rather that not touch any of that code.

#define FALSE 1 is not that uncommon in C because C in its infinite wisdom doesn't have true/false literals so people have to invent those by themselves.

Glib goes into great lengths to avoid namespace conflicts so it defines the GBoolean type and G_TRUE/G_FALSE. Whether that really is better than #define TRUE/FALSE, I don't know.

#define FALSE 0 is the common one

Doh, you're right. I had '#define FALSE 0' in my mind. '#define FALSE 1' actually is insane.

It actually defines TRUE and FALSE, and not G_TRUE/G_FALSE. But it does indeed define the gboolean type - it does make code easier to read.

People don't have to invent them, and it's generally annoying as hell when they chose to.

So then what are they supposed to do, require a library X which has already invented them, while your app is using library Y which already does the same thing as X?

Use 0 and 1, like everyone else. Those #defines are just meaningless syntactical sugar that get in the way.

In C99 #include <stdbool.h> has the type bool and the constants true and false (even in the "freestanding" flavor). Of course this doesn't save you if you are dealing with old/non-conformant compilers and/or legacy codebases.

+1 on dynamic languages, not a fan for this and many other reasons

Haskell seems to go a long way towards solving this problem in my humble opinion. Meaning it can have very dense code but as long as you follow the types it is often fairly straightforward to figure out what a piece of code does.

The worst part about all the things that can happen implicitly in C++ is that they can all have side effects! Oh fun. This is not just a pitfall of C++ either, Java/C# can have the same issue - one statement can trigger a whole plethora of side effects making a large brownfield development project one hell of a nightmare.

As a Haskell fan, I have to say that there is a bag of hurt here as well: performance in the lazy evaluation regime. It can be very hard to predict/understand when thunks are evaluated and the effect it has on heap use.

I am still hoping for a strict, pure language with monads to go mainstream enough to use it.

The next Haskell will be strict - Simon Peyton Jones

Source: http://www.cs.nott.ac.uk/~gmh/appsem-slides/peytonjones.ppt

It is true that the pre-processor can create a lot of confusion, however it is easy to generate a -E version of the file that shows all substitutions. It is not even close to the confusion created by templates, for example.

Reply on news.ycombinator.com