Hacker News Reader

Comment by noonespecial | Hacker News Reader

To be fair, a great deal of programming in today's world consists of using tightly constrained IDE's to glue together libraries and gui kits at very high levels of abstraction. To suddenly ask someone from this tradition to whip out a merge-sort in bare C and then describe it in O notation might be a bit jarring.

The people who built my house likely never took Strength of Materials during their civil engineering undergads, they just follow the building codes and nail together pre-made pieces (sometimes very large pieces) of house.

Would I prefer a PhD in EE to do the electric and a 6 year civil engineer to nail together the boards, just to be sure everything is done right? Perhaps, but I'm sure not willing to pay the extra it would take to make that happen. I still get a decent house with those professionals working a few levels upstream from the builders.

View on HN

The problem with this kind of analogy is that a builder starts with a set of well-defined plans drawn up by some architect or engineer and then executes the house to those specs. The only design document that lives up to that standard when it comes to programming is the full source itself. The part the homebuilders do is what the compiler/linker/toolchain do.

There's a classic essay about this called "What is software design?"

http://www.bleading-edge.com/Publications/C++Journal/Cpjour2...

The problem with this kind of analogy is that a builder starts with a set of well-defined plans drawn up by some architect or engineer and then executes the house to those specs.

I've worked in construction, and a handful of my good friends work in construction of various types. We often laugh at the comparisons between software development and construction. I've certainly never seen a job where the plan worked without modification from beginning to end, and many projects begin with a pile of change orders.

Good link. I have to disagree, however with the assertion that C++ was a step in the right direction. C++ tries to bridge a gap between low-level design and high level design. I think this was a wrong choice to make, because it made it incredibly complex and hard to use.

Many projects don't need to worry about some low levels aspect of the design (if at all): memory management, for instance, can mostly be left to compilers and linkers. When we really need to, we can locally use really low level languages, like C.

> Many projects don't need to worry about some low levels aspect of the design (if at all): memory management, for instance, can mostly be left to compilers and linkers.

And in properly written C++, it is.

No it is not. More precisely, I don't see how you could avoid manual memory management in any significant C++ project. Here's why:

The only memory that is automatically managed in C++ is the stack. (If you disagree, please know that I will be very difficult to convince.) So, "properly written C++" literally means "C++ code which doesn't uses the heap at all". That's probably not what you meant.

Relaxing this rule a bit, you could code in a RAII fashion. That way, the users of properly written objects won't manage the memory themselves. The implementation of those, however, still have to. A prime example is the STL.

Plus, I'm not sure RAII all the way down is "properly written". See, such logic is quite copy-prone, affecting the code's efficiency. You use C++ for it's performance, right? So you have to manage the memory manually at some point.

Or you could use smart pointers. They mitigate the need for manual memory management, and allow sharing. But even then, you might want to (manually) pay attention to loops in the pointing chains.

Relaxing this rule a bit, you could code in a RAII fashion. That way, the users of properly written objects won't manage the memory themselves.

Which is exactly my point: between the standard library and smart pointers, many projects will never have to touch any details of memory management.

The implementation of those, however, still have to. A prime example is the STL.

Of course. But you only need one standard library, and many projects can use it. Don't forget your original claim, which I quoted in my previous post: "Many projects don't need to worry about some low levels aspect of the design (if at all)." It's absolutely true that many sizable projects written in modern C++ never have to consider the low-level details of things like memory management, since those details have been pushed into the libraries they use.

Plus, I'm not sure RAII all the way down is "properly written". See, such logic is quite copy-prone, affecting the code's efficiency.

There are ways to mitigate that impact, if it becomes a performance issue, but it rarely does.

Or you could use smart pointers. They mitigate the need for manual memory management, and allow sharing. But even then, you might want to (manually) pay attention to loops in the pointing chains.

That's only a problem for self-referential data structures, of which there are few not already implemented for you in the standard library.

There are ways to mitigate that impact, if it becomes a performance issue, but it rarely does.

Ah. So you don't really care about performance. In that case, the only justification left to C++ is legacy code. (Knowing Ocaml and Haskell makes me quite certain of it.)

That was my original point: C++, even when you try to use a wisely chosen subset of it, remains very complicated and error prone. I blame it's design choices. I agree that those choices were precisely what made C++ popular, but popularity is hardly a criterion for me. And on all other fronts, C++ really sucks.

So you don't really care about performance.

Did I say that?

That was my original point: C++, even when you try to use a wisely chosen subset of it, remains very complicated and error prone.

Your original point, which I've now quoted twice, was that C++ is inappropriate because many programs don't need to deal with low-level details like memory management. My counterclaim, which you have yet to refute, is that C++ is no obstacle to that end.

I blame it's design choices.

The vast majority of people who blame C++'s design choices don't understand them. Have you read Stroustrup's D&E?

And on all other fronts, C++ really sucks.

Stating a claim is no defense of it.

> > So you don't really care about performance.

> Did I say that?

Yes, by saying that copy prone RAII is rarely an issue. Meaning, performance is rarely an issue. So, you rarely care about performance. That's fine: performance rarely matters, anyway. When it does, we can still locally optimize.

> > And on all other fronts, C++ really sucks.

> Stating a claim is no defense of it.

You're right. This is: http://yosefk.com/c++fqa/ The writing is quite fun, and the whole thing is actually informative. To sum up, the guy says that for a new project with few dependencies, C++ is almost never the best choice. Meaning, (almost) no niche is best filled by C++. Each one is better served with another language.

> Your original point, which I've now quoted twice, was that C++ is inappropriate because many programs don't need to deal with low-level details like memory management. My counterclaim, which you have yet to refute, is that C++ is no obstacle to that end.

You're right (again). I can't refute that point. Now my point is, that doesn't make C++ appropriate. See, when you don't need to do low-level stuff, many programming languages are vastly simpler, safer, more terse, and more flexible than C++. All at the same time. And you can learn them in no time (you were able to learn C++, after all). So, in that case, C++ isn't the best option. Why bother with it?

But still, I wonder how a significant project could avoid to implement some sort of data structure itself (which would mean worry about memory). Do you have any example?

> The vast majority of people who blame C++'s design choices don't understand them. Have you read Stroustrup's D&E?

I didn't. As I understand it, Stroustrup had some goals, and C++ achieved them. One such goal was to bring Object Orientation to C programmers (the "masses"). So I won't say that C++ didn't achieve it's purposes. It did. I just say those purposes weren't worth the behemoth that C++ is.

Object Orientation for instance, is a mistake. As seen by C++ (and Java), OO encourages high coupling and side effects more than is healthy. And that's before you need to apply one of the baroque design patterns from the GoF book.

Yes, by saying that copy prone RAII is rarely an issue. Meaning, performance is rarely an issue. So, you rarely care about performance.

You need to do some work on correcting your faulty interpreter. Saying that copying rarely causes performance problems is not at all saying that I don't care about performance.

You're right. This is: http://yosefk.com/c++fqa/ The writing is quite fun, and the whole thing is actually informative.

Not really. Yosefk, like many C++ detractors, very clearly does not understand the rationale for a number of C++ features. But this isn't the place for me to spend hours refuting a link that too you mere seconds to dig up.

See, when you don't need to do low-level stuff, many programming languages are vastly simpler, safer, more terse, and more flexible than C++.

That's not actually the case, though. For a lot of simple (e.g., scripting) tasks, writing them in C++ results in a program a few small lines longer and orders of magnitude faster. In one case I had billions of integers on which I needed to calculate some simple satistics; while the Python program was running, I was able to write, compile, and run to completion a C++ version that was a mere four lines longer (mostly empty-brace lines).

Some more complex tasks are actually easier in C++ than in other languages. I had to write a parser and virtual machine for an assembly language in college. Doing the bit-level operations in Python would have been a pain, in large part due to the automatic promotion of integers to longs; doing them in C++ was simple and preserved the semantics that I required. I didn't need to manage any low-level allocation in that program; all my "new" calls went straight into smart pointers (auto_ptr actually worked fine in my situation and didn't require a non-standard library) and they handled all deallocation. Valgrind confirmed that there were no memory leaks, with no effort at all on my part.

The vast majority of people who consider C++ difficult to write are unaware (commonly through willful ignorance) of how to write C++ for this the frequently cited issues never arise in the first place.

And you can learn them in no time (you were able to learn C++, after all).

It's not a matter of learning other languages; I'm competent in Python, OCaml, Perl, and a number of other languages I've worked with over the years. C++ is actually a rather late addition to my bevy of languages.

So, in that case, C++ isn't the best option. Why bother with it?

Just because I can learn other languages doesn't mean C++ isn't the best option. Sure, I could similar speed in OCaml, but then I'd be the only one who could work on it, and my employer would be in a tight spot if I were hit by a bus. I could write it in Python or Perl a little bit faster, but it would be an order of magnitude slower, and I'd have to throw tons more hardware at the problem to process the same amount of data.

Object Orientation for instance, is a mistake.

Ah. I see now that I'm arguing with an ideologue. Good day.

It look that we don't agree on the definition of "best". When I judge a language I don't look at the availability of programmers or libraries: that's a short term concern. A valid one, mind you, but one that can stick us to a local maximum.

> [Yosefk don' get it]. But this isn't the place for me to spend hours refuting a link that too you mere seconds to dig up.

Actually, I've read the whole thing. And a good deal of the FAQ as well. Also, I think there is a good chance that Yosef did understood the rationale behind C++, but was challenging it nonetheless.

> Ah. I see now that I'm arguing with an ideologue.

I know my statement contradicts 99% of the industry. But I don't have much choice. Basically I believe 2 things: (1) side effects, like assignment, should be avoided or isolated, and (2) coupling between modules should be minimized. OO as I see it violates both principles: objects are state-full by default, and coupling is often high (many methods per class, inheritance). The conclusion is inevitable: either I don't "get" OO, or my beliefs are false, or 99% of the industry is making a mistake.

Now I don't believe that OO is always a mistake. I just believe that for most problems, it is a mistake to apply an OO solution.

(Note that I say "believe", not "think". Actually, I am still full of doubts).

Distinguish between architects,designers and coders. Different skills needed at each level of solution design.

Just google the fizzbuzz problem, people struggle to solve even simple problems. Here's a link: http://www.codinghorror.com/blog/2007/02/why-cant-programmer...

What you say is true, but I don't think that's what he's saying.

When I was in school, I saw my classmates fail to grasp basic concepts and abstractions. They had no deeper understanding. They managed to regurgitate the things they'd heard for a test, work together and manage to get an okay project together, and pass by by the skin of their teeth. They'd complain about how C was too hard, how badly they'd failed an assembly assignment, and that they couldn't wait to get back to Eclipse and Java. Of course, they'd only have one huge, giant class.

It's incredibly unfortunate. I'm not sure how to fix this. Maybe my standards are just too high.

I think his point was that some very important software might end up being written by those people who could not grasp the fundamentals of CS. I've seen recursion fail to fit into the minds of some otherwise very bright individuals.

What I'm not entirely sure of is that decent financial/industrial/important software can't be written by someone who can't write an algorithm to sort an array. You don't need to know much CS to call array.sort(), only that you want the array to be sorted. Now this level of engineer might not know what to do if it doesn't work (or worse, works but badly) but if he's got enough domain knowledge otherwise, he'll know to spend some money on a few high dollar hours with someone who can fix it.

I'd rather have someone who's a very good EE who didn't quite grok recursion working on my power grid software than a very good programmer who can't tell an amp from a volt. At least the EE can tell when its broken.

The author was surprised that candidates came to him with actual accomplishments on their resumes but didn't seem to know the basics of CS. My counterpoint was that its probably possible to accomplish quite a lot without knowing the basics these days, and if you do it cheaply, that might be just fine.

Yea, there's a big trend in programming to make it simpler, frameworks and languages that let you get more done while thinking about less. It's suddenly important to understand the underlying principles?

I don't think that message will get through with those distracting frameworks everywhere.

"I'd rather have someone who's a very good EE who didn't quite grok recursion working on my power grid software than a very good programmer who can't tell an amp from a volt. At least the EE can tell when its broken."

A great deal of terrible, buggy, unmaintainable software has been written due to exactly this type of sentiment. I have maintained, re-written, built on top of this type of software. The correct way to build power grid software (or any science/engineering-related software) is by having very smart software engineers (who do understand or can quickly figure out things like recursion), working closely with electrical engineers (or biologists/chemical engineers/etc). As in, they should be in constant (at least weekly) contact with each other. The software engineers learn about electricity, and the electrical engineers learn a little about software architecture.

This is based on my experience developing software for engineering applications. I currently work on software in the Aerospace industry, and I communicate regularly with other engineers. My software team is full of brilliant software engineers. Smart people can learn about other fields on-the-job. If you accidentally hire one that can't, don't fret: there is always work that doesn't require an intimate knowledge of electronics, such as build scripts, support software, utilities, etc.

That being said, I do think there is a place for a software engineer with a passion for other types of engineering. My degree is in Bioengineering, but my greatest experience (and greatest interest) is in software engineering. So, while I grok differential equations, control systems, and metabolism, I also understand recursion and polymorphism. And deterministic finite automaton. And closures. And I'm not the only one.

My point is this: If you have a really hard engineering problem that requires really smart software, hire really smart programmers, really smart engineers, and a couple really smart people who understand both sides. Like me!

Reply on news.ycombinator.com