5 ms·

Agreed. I recently started working in C++ after spending a lot of time with more traditional web application languages like Ruby, Python and Clojure. It was sho

by lbarrow 13y ago

Agreed. I recently started working in C++ after spending a lot of time with more traditional web application languages like Ruby, Python and Clojure. It was shocking to see how grotesque and overbuilt the language was compared to the tools I was used to. I don't think I was just having sticker shock due to the relative lack of power and expressiveness of C++. I expected to spend time managing memory, recasting objects, etc -- that didn't surprise me. Instead, I was surprised by how badly different parts of the language play with each other, and how many more parts C++ has. ANSI C has about 30 keywords. C++98 had about 30 more. C++11 adds even more. All of these language constructs have complicated relationships with each other, often filled with gotchas and traps. Compare this with the ~30 keywords in Python (and even less in Clojure). If I'm bound by CPU performance nowadays (which doesn't happen often), I'd use Go or a JVM language. If I absolutely had to, I'd consider C. But never C++.

btilly 13y ago
I am currently doing a small performance intensive project in C++, and my take is that C++ has been a good fit for this. But you have to consciously decide at the start what set of features that you will use. And no more. Because C++ has multiple usable subsets. Find one. Stay within one. Avoid confusion. (Particularly if, like me, you're not a C++ programmer and don't wish to become one. Then you can have a clearly defined boundary of what needs to be learned for the project.)
- nicholassmith 13y ago
  I recommend anyone using C++ to do this exact thing. It's the sanest way to use it without driving yourself mad when something no longer works because X causes issues with Y.
kunai 13y ago
Any Rubyist or Python developer will be caught off-guard with C++. Dynamically typed languages are intrinsically easier, and languages like Python and Ruby do garbage collection for you, resulting in a lot less work for the developer. C++ does none of that. It's a slightly higher-level modification of C with object-oriented features, and C is still a lower-level language closer to, say, ALGOL or Simula rather than higher-level like Java or Smalltalk. Adding OOP still retains the hardware control and all of the bad stuff that comes with it (segfaults, buffer overflows, etc.), but adds complexity. C++ is complex. Twisted. Mangled. But it's powerful, and you can do things in it that you could never dream of doing in C, Java/Jython/Mono, Python, Ruby, or Go. It's like a Mitsubishi Lancer Evolution. It's a pain in the ass to deal with on a daily basis, but its potential is simply unmatched by any other vehicle in its price range. There are others that are more comfortable. But none reach the capability and sharpness of the Evo. C++ is the Evo.
- gizmo686 13y ago
  >Dynamically typed languages are intrinsically easier I don't think this is necessarily true. Dynamic typing moves an entire class of bugs from compile time to run time. And, I am not aware of what benefits it brings (other than minor expressiveness) that can not be had in a static type system. For the most part, you will right code assuming a variable has a given type. If that is not the case, you will get a runtime error instead of a compile time error. In the cases where the variable can be multiple types, doing so in a static type system can be as simple as declaring the type to be polymorphic (or as horrible as java generics, or as hacky as void*). The other advantage of dynamic type systems is that they often come with autocasting. While both of these do provide some expressiveness, working around them in statically typed isn't really complicated, just a minor amount of boiler plate. The main awesomeness of Python's type system (and maybe Ruby's, I've never used it) isn't dynamic typing, but duck typing. The idea hear is that you almost never care what type an object is, only if it supports a given method. For example, if I define a new object, and define a method 'read()', I can pass it into a function that was expecting a file, so long as it only calls the 'read()' method. Of course, avoinding garbage collection is still a big advantage.
  - btilly 13y ago
    I'd be hard pressed to name a popular dynamically typed language that does not offer duck typing. Technically there may be a distinction, but it is not one that matters. The thing that I find creates the most boilerplate for me with static typing is useless helper classes that only exist to get around the fact that class A owns object of type B, so you don't want to allow an object of type B have a method that requires its parent A. Instead you create a class C owned by A which everything that B needs for that call can move into, and then let B know about C. (It does not much matter whether you make A inherit from C, or make C owned by A. Though I stylistically strongly prefer the second.) Yes, you can set up mutual recursion between two classes in C++, but this involves some gymnastics and is frowned on. In a dynamically typed language you'd just pass objects of type A into a method for type B. Refactoring out a whole new class out of an existing one is not "a minor amount of boiler plate" in my books. But that is what C++ pushes you to do.

by lbarrow 13y ago

btilly 13y ago

I am currently doing a small performance intensive project in C++, and my take is that C++ has been a good fit for this. But you have to consciously decide at the start what set of features that you will use. And no more. Because C++ has multiple usable subsets. Find one. Stay within one. Avoid confusion. (Particularly if, like me, you're not a C++ programmer and don't wish to become one. Then you can have a clearly defined boundary of what needs to be learned for the project.)

nicholassmith 13y ago
I recommend anyone using C++ to do this exact thing. It's the sanest way to use it without driving yourself mad when something no longer works because X causes issues with Y.

kunai 13y ago

Any Rubyist or Python developer will be caught off-guard with C++. Dynamically typed languages are intrinsically easier, and languages like Python and Ruby do garbage collection for you, resulting in a lot less work for the developer. C++ does none of that. It's a slightly higher-level modification of C with object-oriented features, and C is still a lower-level language closer to, say, ALGOL or Simula rather than higher-level like Java or Smalltalk. Adding OOP still retains the hardware control and all of the bad stuff that comes with it (segfaults, buffer overflows, etc.), but adds complexity. C++ is complex. Twisted. Mangled. But it's powerful, and you can do things in it that you could never dream of doing in C, Java/Jython/Mono, Python, Ruby, or Go. It's like a Mitsubishi Lancer Evolution. It's a pain in the ass to deal with on a daily basis, but its potential is simply unmatched by any other vehicle in its price range. There are others that are more comfortable. But none reach the capability and sharpness of the Evo. C++ is the Evo.

gizmo686 13y ago
>Dynamically typed languages are intrinsically easier I don't think this is necessarily true. Dynamic typing moves an entire class of bugs from compile time to run time. And, I am not aware of what benefits it brings (other than minor expressiveness) that can not be had in a static type system. For the most part, you will right code assuming a variable has a given type. If that is not the case, you will get a runtime error instead of a compile time error. In the cases where the variable can be multiple types, doing so in a static type system can be as simple as declaring the type to be polymorphic (or as horrible as java generics, or as hacky as void*). The other advantage of dynamic type systems is that they often come with autocasting. While both of these do provide some expressiveness, working around them in statically typed isn't really complicated, just a minor amount of boiler plate. The main awesomeness of Python's type system (and maybe Ruby's, I've never used it) isn't dynamic typing, but duck typing. The idea hear is that you almost never care what type an object is, only if it supports a given method. For example, if I define a new object, and define a method 'read()', I can pass it into a function that was expecting a file, so long as it only calls the 'read()' method. Of course, avoinding garbage collection is still a big advantage.
- btilly 13y ago
  I'd be hard pressed to name a popular dynamically typed language that does not offer duck typing. Technically there may be a distinction, but it is not one that matters. The thing that I find creates the most boilerplate for me with static typing is useless helper classes that only exist to get around the fact that class A owns object of type B, so you don't want to allow an object of type B have a method that requires its parent A. Instead you create a class C owned by A which everything that B needs for that call can move into, and then let B know about C. (It does not much matter whether you make A inherit from C, or make C owned by A. Though I stylistically strongly prefer the second.) Yes, you can set up mutual recursion between two classes in C++, but this involves some gymnastics and is frowned on. In a dynamically typed language you'd just pass objects of type A into a method for type B. Refactoring out a whole new class out of an existing one is not "a minor amount of boiler plate" in my books. But that is what C++ pushes you to do.