What is Reddit's opinion of Compiler design in C (Prentice-Hall software series)?

From 3.5 billion Reddit comments

Thank you for your candid response.

Clearly, you feel very passionate about C++ & I can respect that, you see an opinion that you don't think is inaccurate according to your personal experience & you want to address it. But just because you like C++ doesn't mean everyone does. Can you accept this?

I coded professionally in C++ in the late 90s & early 2000s I was a fan, drank the kool-aid & then I learned about other languages & paradigms & I saw the light & I have looked back to see what is like to code in it with the new standards but I still think it sucks, because I know better alternatives to C++ & got more experience to judge C++.

Many people in the world don't share what you feel about C++ & that is something you have to live with because we all have personal experience that has produced our opinion about C++. You think we don't know C++ but we do, and it is funny to me because your opinion reflects to me that the only thing you know is C++ that you only have read a "C++ is awesome" book full of examples of why C++ is better than C and that is why you think something like >Writing good C++ does not require any more discipline than writing good Haskell code. Which to me is a trillion times more of an abomination than considering that C & C++ are similar. This is the point that screams inexperience from you dude because a Haskell compiler helps you a lot more than C++'s to get the same level of help with C++ you need external Static Analysis tools & run them every single time after you compile. Because C++ has no Hindley–Milner type system and is weakly typed, it allows you to use a lot of legacy stuff that is not good, C++ isn't Lazily evaluated, & using libraries that run lazy algorithms doesn't count because it is a completely different experience.

>>If the author is making the question is probably because he knows C but he doesn’t feel sure about C++ and it’s features >The OP hasn't said anything that could suggest this? Are you in the spectrum? do social cues are difficult for you? I'm asking honestly because I don't know you. Probably we just have different ways to analyze some things but If someone is asking a question there is a reason behind it and it isn't just to get the direct "test answer" for the question because he is going to use the answer within his own cultural and experiential context, the author might not suggest anything voluntarily or intentionally but he is asking the question for a reason, don't be naive or socially clueless enough to think otherwise.

>>It is like tipping with the toes >C and C++ should be approached as any two different languages. People who learn C++ starting with C end up getting stuck with old ways of thinking and write, on average, worse, less idiomatic, ugly C++.

If you wanna write idiomatic code in any language it has to be approached as a different language, that is true and what I said never suggests differently, that was you jumping to conclusions. Also, this comment of you tells me you don't have experience because when you work in a team you know that you will write code that you think is good and idiomatic but others will think it isn't and others will write code they think is idiomatic but you think it isn't that is why teams in companies use "style guides" to avoid such bike shed.

The reason I suggested a minimal C++ as a better C is that V8 the javascript runtime of Chrome is coded just like that, the authors of the project avoid classes and stick to using structs with external functions, they want to code with a minimal set of features that they do understand at all semantic levels because V8 is a huge project and they also have to deal with Javascript semantics. Also, it makes sense when your objective is to keep coding in C and not in C++ but using a C++ compiler comes with better optimizations that your average code in C can take advantage of but they are not part of the C-compilation toolchain, because those optimizations are based on the standard of C++ and not on the standard of C.

tipping with the toes is something that many developers do, that is why many Java developers learn Scala to learn FP, which in the case of learning FP I think it doesn't make sense but people do that because they want to reduce the effort they invest in something. Writing ugly unidiomatic code is not bad, writing buggy code is. In the case of Haskell it matters because Haskell is different in every way, is Lazily evaluated, immutable, the type system is so different and, has no OO (which is the standard) and this is completely different to what Java or C++ offer FP is a completely different paradigm to OO so it has to be learned in its pure context to be able to distinguish.

But with C & C++ the paradigms are a lot closer than you think, you are missing the forests (yes in plural) for the leafs of a single forest, OO is as procedural as C is. The only difference is in how code is organized in C you have types independent of their code only tied by type descriptors in procedure declarations, but Classes in C++/Java and every other programming languages with classes, and in a generic way classes are just Modules combined with types to exploit single dispatch, they are just syntactic sugar.

Read this book Compiler design in C (Prentice-Hall software series) It shows you a hacky way to do OO in plain C taking advantage of how the C compiler handles things, showing the old ways of coding OO in C without C++

The thing is OO is a lot more than single dispatch, OO in C++ sucks. The Actor Model (and read Hewit's paper before making any wrong comments about it) is what OO was supposed to be but Alan Kay failed to implement it with Smalltalk because he was too influenced by Simula (which started as just a library for ALGOL) & LISP1.5. But Bjarne just copied what he liked from Simula and made the horrible pseudo-OO of C++. This is also why is Frankenstein, because when you know the other languages and how well they integrated everything, you see what C++ is and you feel sorry for it.

There are studies where a program is asked to developers with different skill levels in different languages and they give them all the time they wanted to satisfy the requirements, they give them a very long deadline so it could accommodate even slower newbie developers. The purpose of the experiment was to find the best programming language in terms of budget vs quality of the software produced. And the people who chose C++ were terrible they took more time than almost everyone else and produced buggy code. While Haskell wasn't the fastest, wasn't the slowest it was between the faster and fastest blocks but the remarkable par was it had the least number of bugs in the entire experiment. Lisp was the fastest in dev time but it had tons of bugs, the lisper was a newbie you could tell he didn't even code in a REPL.

If you have experience coding software professionally with different paradigms you learn to value more a language for how much can it help you to productivity vs how fun it is to solve the challenges or how much you learn in it, so features like manual memory management, or having every instruction changing state under the rug are the worst for productivity because you cannot reason about code clearly with just reading so you can introduce tons of code that looks good but when its compiled and tested there is a ton of edge cases you haven't thought about, and then you invest time in removing those bugs but when you add something new crashes with what you have before and you have to rework again and again. If you have experience programming with Functional programming even if it is without a sophisticated type system, like Common Lisp for the programming style of Higher-order Functions you are doing some side effect management.

And this isn't just my opinion, it is also other people's opinion, Rich Hickey for instance the creator of Clojure, he had said this anecdote when he was introducing Clojure to the Java community in the late 2000s, He was a freelancer with 15 years of experience in C++, and he had been learning Common Lisp for 6 months (so 15 years 6 months of experience) so when he got a new customer he thought "cool I can do this in Common Lisp", he did it and when he delivered the code the customer told him "Well, it looks great and all but we got infrastructure aimed at C++ so we need the software in C++" then Rich though cool I can do it, is a piece of cake and he took 3 times in working hours to do the same software.

Developing deliverable software in C++ is slow.

And you said "but the new standards..." cool, the problem is that most C++ shops are still on the old way and they don't want to introduce the new standards because they don't know them & prefer to invest their time in billing customers than learning new things. I think this sucks & is a negative attitude but that is the reality of the society we have to accept.

Because Type Driven Development with something like Haskell or Elm helps you to be productive and invest your time in moving on in features and reduce drastically the total number of failures, bugs, etc.

Also because as a Lisper & Haskeller, I see C++ metaprogramming as a world of pain. Even Lisp Fexprs with vau-calculus are a lot better than C++ templates.

<em>Compiler Design in C</em> is also good. It'll take you step by step, building a compiler.