4 ms·

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 call

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.

fleitz 16y ago
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.
- asomiv 16y ago
  #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.
  - tmp43522 16y ago
    #define FALSE 0 is the common one
    - asomiv 16y ago
      Doh, you're right. I had '#define FALSE 0' in my mind. '#define FALSE 1' actually is insane.
  - kklimonda 16y ago
    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.
  - burgerbrain 16y ago
    People don't have to invent them, and it's generally annoying as hell when they chose to.
    - asomiv 16y ago
      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?
      - burgerbrain 16y ago
        Use 0 and 1, like everyone else. Those #defines are just meaningless syntactical sugar that get in the way.
  - exDM69 16y ago
    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.
nightski 16y ago
+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.
- danieldk 16y ago
  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. 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 http://www.cs.nott.ac.uk/~gmh/appsem-slides/peytonjones.ppt
coliveira 16y ago
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.

fleitz 16y ago

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.

asomiv 16y ago
#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.
- tmp43522 16y ago
  #define FALSE 0 is the common one
  - asomiv 16y ago
    Doh, you're right. I had '#define FALSE 0' in my mind. '#define FALSE 1' actually is insane.
- kklimonda 16y ago
  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.
- burgerbrain 16y ago
  People don't have to invent them, and it's generally annoying as hell when they chose to.
  - asomiv 16y ago
    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?
    - burgerbrain 16y ago
      Use 0 and 1, like everyone else. Those #defines are just meaningless syntactical sugar that get in the way.
- exDM69 16y ago
  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.

nightski 16y ago

+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.

danieldk 16y ago
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. 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 http://www.cs.nott.ac.uk/~gmh/appsem-slides/peytonjones.ppt

coliveira 16y ago

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.