Well, if you haven't encountered any brain-bending Javascript, you haven't gotten very far into Javascript.
C++ and the Culture of Complexity (2013)
241–250 of 285 posts
Re: C++ and the Culture of Complexity (2013)
#242Earlier quoted context omitted.
http://www.walterbright.com/ > Walter Bright is the creator and first implementer of the D programming language and has implemented compilers for several other languages. He's an expert in all areas of compiler technology, including front ends, optimizers, code generation, interpreter engines and runtime libraries. Walter regularly writes articles about compilers and programming, is known for engaging and informative…
Thanks, but my reply was for notacoward. Unfortunately I can't edit or delete it any more.
Oh, er, sorry about that.
Re: C++ and the Culture of Complexity (2013)
#243Earlier 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…
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.
Re: C++ and the Culture of Complexity (2013)
#244Earlier quoted context omitted.
I feel like embedded development should just avoid c++ and go with a managed languages. I was hopeful abut go, but they kinda wrecked it for embedded. The thing with embedded is you have two cases, hard real time and just don't care.
They go with Java in very specific cases, but you need big bucks to pay for something like PTC Perc Ultra, JamaicaVM or WebSphere Real Time. Then there is microEJ as well, but their target is that performance critical code is anyway written in C and exposed to Java. Also depending how embedded one might consider mobile phone hardware, there is Android and Android Things. Then there are some OEMs still selling Basic,…
I've seen some people using MicroPython combined with C in embedded devices. Or plain Python on embedded Linux doohickeys. Company I work for has a few embedded Linux devices running Python.
Re: C++ and the Culture of Complexity (2013)
#245The bullet list near the end closely matches my own experience with C++. There's an inordinate number of features creating an even worse profusion of edge cases where they interact. Then the "solutions" for those edge cases usually add even more complexity. Worse, they force programmers to coddle their compilers. The ratio between what a C++ compiler will accept and what it will produce sane code for is huge . That's…
How is Rust less complicated than C++? I don't use it, but from what I read it seems to be even more complicated, and getting even more so with the myriad of features they are adding each release.
Rust mostly avoided accidental complexity. The complexity it has is mainly from tackling a complex problem of providing memory safety and preventing data races at compile time.
In C++ a large chunk of complexity comes from legacy of being a C superset and having to preserve backwards compatibility with all of its old features and syntax quirks, and often surprising edge cases arising from interactions between different features.
Re: C++ and the Culture of Complexity (2013)
#246Earlier quoted context omitted.
just a contrary opinion. I read the c++ book in the very early 90s. someone told me it was the future of programming. every single c++ shop I've worked at since has said, 'well, yes the language is a mess, but if you stick to a well controlled subset, its really pretty good' and all of those shops, without exception, have dragged in every last weird and contradictory feature of what is a really enormous language. so…
"dragged in every last weird and contradictory feature of what is a really enormous language" This happens with every language that has a lot of features. You have to try them before you can form an opinion.
> This happens with every language that has a lot of features.
Seems like the key is to not have a lot of features, then.
Re: C++ and the Culture of Complexity (2013)
#247Earlier 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…
About your two realizations:
1. I've "exposed" parts of the private implementation in that they were in the header file, yes. They were also labeled "private". That means that someone can read that and gain more information about my implementation then they could from just public information, I suppose. It also means that nobody can actually use them in code, because they're private. So you can think of that as "exposing" if you want, but it's not something that I've ever recognized as any kind of a problem, let alone one worth solving.
2. If you change only the private parts of the class and try to link other code to it without recompiling the other code, yes, you can get a broken compiled binary. That is certainly true. But I could do that in C almost as easily (if everything that uses the struct layout isn't in the same source file). And makefiles that keep track of dependencies aren't exactly rocket science. Neither are clean builds.
Maybe I just don't have your problems, but I'm still not seeing this as much of an issue at all.
Re: C++ and the Culture of Complexity (2013)
#248Earlier quoted context omitted.
"dragged in every last weird and contradictory feature of what is a really enormous language" This happens with every language that has a lot of features. You have to try them before you can form an opinion.
> This happens with every language that has a lot of features. Seems like the key is to not have a lot of features, then.
But languages with not a lot of features trap you unless you never need that feature (or unless you're fine with implementing that feature yourself in what the language gives you).
Re: C++ and the Culture of Complexity (2013)
#249Earlier 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.
I used C++ for embedded CPU 68332 (25 MHz CPU) with 4MB of SRAM in ~1996 for DNA sequencer machine. ~100 + classes, single inheritance, 1,2, 3 Axis motor controls, CCD Camera, Laser, serial com channel, scripting engines, etc. No template, no virtual functions. Worked very well at that time. The compiler setup at that time is AT&T cfront generate C from C++ code ran in Mac and embedded C cross compiler generated the…
Sounds like a sweet spot kind of project for C++.
Re: C++ and the Culture of Complexity (2013)
#250Earlier quoted context omitted.
It seems to have many fewer language-level features. No lvalue/rvalue distinction, pointers are not elevated to a language-level feature (only references), only a very limited exception mechanism (panic) that doesn't try to generalize to support general validation (rather general validation is done with Result which is a plain old datatype written in the language, though admittedly it relies on a macro for use - more…
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 !)