C++ and the Culture of Complexity (2013) • Hacker News Board

Re: C++ and the Culture of Complexity (2013)

#251

Post by virmundi » Thu, Feb 01, 2018, 2:19 AM UTC

kamaal wrote: post #103

virmundi wrote: post #14

Earlier quoted context omitted.

I find Spring to be great. I grant that I've used it since 2.0, but really it does everything quickly, easily, and is well documented. Especially with Spring Boot. I'm writing a core service in Go because Java 9 broke a Maven plug-in (that I don't need now). Holy crap is it painful. I know that I'm learning, but it's hard to layer the application. Most tutorials show passing the database connection through all of the…

>>Really, I don't think that Java brings that much complexity now. It use to. That's because these days you don't learn Java, you learn things that manage Java madness. Like Eclipse, IntelliJ or Maven etc. You don't really do much using Java these days. You do things using tools, which write bulk of the Java code. In essence learning Java today is learning Java ecosystem tools. >>But you can get a new developer up an…

What you do see is people abandoning the "prototype languages". At least twice a year HN has a story where some company dropped Python, Ruby, etc. in favor for Java. They didn't just port to the VM for Jython or JRuby. They re-made the whole thing in Java.

Why not skip this step and just use Java. Yes, there's great tooling that makes Java easy to use. That's the point. You don't have to use JavaBeans for JSON. Expose the properties as public. Jackson's got your back.

Fundamentally, a good design has bounded contexts. The web API should not directly expose your domain objects to the Internet. There should be a mapping between the service boundary to at least the use case boundary. Exposed properties are find for DTOs like JSON bodies. Map those to your domain objects via a translator and you're good. A lot of bulk drops with this approach.

As a language, yes Java is a bulky. But it's wonderfully readable. I know what type a variable is without having to dumpster dive into the method invocation (looking at you Python and Go). I can know directly through a type hierarchy which components implement an interface. In Go you have to explicitly set the supposed implementation to a throwaway variable just to have the compiler tell you if it works. Yes, checked exceptions are a pain. We know that. When it came out, it was a theoretical good. Unlike Go, at least you can wrap a checked exception with a runtime and move on with your code.

To this day Java is the balanced language between performance and usability (along with C#). It is showing its age. It does need some renovation, but on the whole it's a fine language to do new things.

Re: C++ and the Culture of Complexity (2013)

#252

Post by flukus » Thu, Feb 01, 2018, 3:26 AM UTC

snarfy wrote: post #130

clishem wrote: post #18

Earlier quoted context omitted.

Sure, it's a large and complex language that takes time to master. But I'm interested to hear examples of what you call 'profusion of edge cases'. > The ratio between what a C++ compiler will accept and what it will produce sane code for is huge. As is the case for any programming language. > C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security. C++ is de…

> C++ is designed by its standards committee... When it comes to design, C++ is a good example of why having a benevolent dictator is better than a committee. I still think it's a huge mistake to not have a standard ABI and rely on C's ABI.

> I still think it's a huge mistake to not have a standard ABI and rely on C's ABI.

And rust is going down the same path. Looks like c will reign supreme for shared libraries for the foreseeable future.

Re: C++ and the Culture of Complexity (2013)

#253

Post by blt » Thu, Feb 01, 2018, 4:38 AM UTC

yason wrote: post #240

AnimalMuppet wrote: post #218

Earlier quoted context omitted.

Could you give an example of "some basic things are so fundamentally convoluted"? Also note that almost all C code is legal C++, so when you "just write idiomatic C", you're still writing C++. (Perhaps not idiomatic C++...)

A simple case is hiding the implementation and exposing a public API. Let's use objects to make it something C++ ought to be good at and C ought to be bad at. In C, you write a header file adder.h: struct Adder; struct Adder *adder_create(void); void adder_setup(struct Adder *, int, int); int adder_operate(struct Adder *); void adder_delete(struct Adder *); You can easily imagine how one would trivially implement the…

It's convoluted because the idea of forcing an object to always be allocated on the heap is convoluted. The real fix for this problem is the modules system, where the compiled module can expose an object's size without exposing its contents. Your example shows why header files suck more than anything about the core semantics of C++ as a language.

Re: C++ and the Culture of Complexity (2013)

#254

Post by [deleted] » Thu, Feb 01, 2018, 6:03 AM UTC

humanrebar wrote: post #178

oselhn wrote: post #89

Earlier quoted context omitted.

I agree that C++ is bad but I actually find C much worse for projects bigger than a few thousands of lines. Reasons for this: * lack of namespaces - all names with long prefix look the same to me * just text based macros * no generics * error handling usually based on int constants and output function parameters - in big projects is hard to use them consistently without any type checking * no polymorphism * ton of un…

> no polymorphism C has plenty of polymorphism. The compiler just doesn't do it for you. In fact, C++ started out as C-with-classes since it was a pain to keep recreating the OOP-in-C boilerplate over and over. Besides, there are more kinds of polymorphism than virtual methods. You can be polymorphic with an array of function pointers.

[deleted]

Re: C++ and the Culture of Complexity (2013)

#255

Post by pjmlp » Thu, Feb 01, 2018, 6:09 AM UTC

antonvs wrote: post #243

pjmlp wrote: post #80

Earlier quoted context omitted.

Very very slowly. Only now embedded development is starting to accept C++, and C still rules there anyway. Which means it took about 20 years to reach this point. And still Rust will need to go through the same certification processes that C, C++, Ada and Java enjoy for such scenarios.

What do you mean by embedded systems? Here's an article from 1998 that gives an example of C++ being used in military avionics systems: http://www.cs.wustl.edu/~schmidt/TAO-boeing.html It's been used in civilian avionics for a long time, too. Not that it's necessarily the best choice in those environments, but "starting to accept" seems like a mischaracterization.

I mean the embedded systems where Assembly and C89 still rule, and there is very hard to change, because the problem of adopting anything else is cultural.

Basically, while there are projects being done in C++, and many companies are finally migrating from C to C++, the large majority is sticking with C.

If you prefer to listen to someone actually relevant in the C++ embedded community, here is what Dan Saks has to say about it.

https://youtu.be/D7Sd8A6_fYU

http://cppcast.com/2016/10/dan-saks/

Re: C++ and the Culture of Complexity (2013)

#256

Post by ndh2 » Thu, Feb 01, 2018, 6:32 AM UTC

gpderetta wrote: post #121

ndh2 wrote: post #81

Lots of posts here frame it like "Yes, it's a bit of a complex language, but the C++ committee has the difficult job of keeping everything backwards compatible, so it's understandable." But that's not the reality. The reality is that they (or Stroustroup) made that decision, and that decision was a mistake. The correct way to deal with backwards compatibility issues is the way Go does it, namely to write tools to aut…

Backward compatibility with C semantics and tooling was fundamental for C++ success. We wouldn't be having this discussion otherwise as nobody would have used C++. Tools are great for minor upgrades of APIs and syntax, but key to C++ was compiling with existing system headers (no, realistically you do not want to maintain your own 'fixed' version), and most importantly OS and library ABI.

I agree. I said that it was a mistake, but in the beginning it really wasn't. It's just not a viable long term strategy in my view.

Re: C++ and the Culture of Complexity (2013)

#257

Post by carlmr » Thu, Feb 01, 2018, 7:58 AM UTC

notacoward wrote: post #133

cageface wrote: post #76

Earlier quoted context omitted.

C++ is a mess but it's one of the few languages that gives you low-level control of memory and fast code with zero or near zero cost abstractions. So for a certain class of application it's still the best choice. Music software, for example, is pretty much exclusively written in C++. I don't enjoy C++ the language very much but you can build some very cool things with it. Personally I'm hoping Rust displaces it from…

> it's one of the few languages that gives you low-level control of memory and fast code with zero or near zero cost abstractions. So for a certain class of application it's still the best choice. For a certain class of program , you mean. For applications specifically, the advantages you mention are barely relevant. Usually only small parts of a whole application need low-level control of memory etc. Those can be wr…

>For a certain class of program, you mean. For applications specifically, the advantages you mention are barely relevant. Usually only small parts of a whole application need low-level control of memory etc.

I'd say Rust has a similar level of control. I just rewrote our longest build step (37 minutes on a normal build) in Rust. By having control over when things are allocated I could get it down to about 20 seconds. The previous software is written in Java.

If you want speed you need to choose C, C++ or Rust. If you want it safely, then Rust. I'd argue in my case that Rust was probably the fastest choice. As I probably would have copied more in C/C++. In Rust I can trust that my memory is intact.

I'd also choose C over C++ though. I find it's a much more manageable language. I never found it hard to make the right abstractions in it, except for maybe a lack of generics (which C11 kind of solves for).

Re: C++ and the Culture of Complexity (2013)

#258

Post by carlmr » Thu, Feb 01, 2018, 8:32 AM UTC

lowbloodsugar wrote: post #200

gpderetta wrote: post #156

Earlier quoted context omitted.

The header inclusion model (where you will be textually including hundreds of thousand lines of random code in a translation unit) doesn't make it easy to have version flags. Also many of the issues are intrinsic to the way the language has evolved (the template compilation model for example), it is not just a matter of deprecating a few features here and there (although that might help)

Headers are what need fixing first. They are why I would never consider using C++ for any new project and avoid jobs that require maintaining C++ code. C++ is the steam power of computing and keeping legacy monoliths running doesn't do anyone any favors. That shit should have been piece-by-piece rewritten by now.

You're forgoing all of the sweet cash that C++ legacy maintainers will make in 20-odd years. Like the COBOL people right now.

Re: C++ and the Culture of Complexity (2013)

#259

Post by masklinn » Thu, Feb 01, 2018, 8:37 AM UTC

steveklabnik wrote: post #250

masklinn wrote: post #216

Earlier quoted context omitted.

FWIW > Result which is a plain old datatype written in the language, though admittedly it relies on a macro for use It does not. It relies on a special construct (!) or macro (try!) for convenience , but these are not necessary (a popular alternative is to use the various HoFs instead) and desugar to pretty trivial (if possibly repetitive) code: macro_rules! try { ($expr:expr) => (match $expr { $crate::result::Result…

(It's ? not !)

(You're right of course, not sure what I was thinking)

Re: C++ and the Culture of Complexity (2013)

#260

Post by Animats » Thu, Feb 01, 2018, 8:37 AM UTC

One word: Boost.

C++ went off into template la-la land some years back. C++ templates were not supposed to be a programming language. But they turned into one, and not a good one.

Look up the implementation of "max" and "min" in C++ templates.

Now there's a push for "move semantics", to keep up with Rust and the cool kids. But not with language support and a borrow checker. With templates and cute tricks with the type system.