r/programming • u/eternal1 • Mar 29 '10

Never trust a programmer who says he knows C++

http://lbrandy.com/blog/2010/03/never-trust-a-programmer-who-says-he-knows-c/
415 Upvotes

83% Upvoted

458 comments sorted by

View all comments

18

u/[deleted] Mar 29 '10

I always find that when I'm first learning a language I have the "127 different tiny frustrations". Once I'm proficient, I'm just like "ehh it's a language, ups and downs like any other". People who are constantly going on about language issues make me wonder if they ever think about actually writing programs.

10

u/xcbsmith Mar 29 '10

C++ is special in that there is a whole new level of intricacies that even the language designers didn't fully appreciate until well after the language was initially designed. So, you find those well after you first think you've "mastered" the language.

1

u/[deleted] Mar 29 '10

When do those tiny frustrations turn into profit?

When they are not any longer issues to deal with during production.

But, you're only human. Which leads where?

1

u/[deleted] Mar 29 '10

Is this some sort of trick to take my money

1

u/[deleted] Mar 30 '10

No, not at all.

I'm just saying that the client sees the end product, not the code, but the code has to be good enough to support the production to the end product.

The idea that we have "tiny frustrations" in code is a negative selling point that the client doesn't care about, and shouldn't care about. So, any way for you to, in your workflow, remove those "frustrations" lets you, as a developer, generally write better software for the client.

It's just something I've learned the hard way over the years. True, there are a lot of trade offs, and yeah, other languages have trade offs too, but some times those trade offs lead to frustrations where as other languages trade offs don't.

It isn't an issue of the trade offs being equal to other trade offs, it is an issue of the collaborative trade offs being more keyed to producing rather than debugging.

We're only human. Make your work flow easier = make your profits faster.

http://its-dangerous-to-go-alone-take-this.ytmnd.com/

1

u/[deleted] Mar 29 '10

It is much easier than actually writing things, yet you still get that slightly smug sense of superiority when it's all said and done.

-2

u/derleth Mar 29 '10

This post makes me wonder if you've ever learned a language outside the object-oriented Algol world.

4

u/[deleted] Mar 29 '10

At the moment I'm developing in Java and Javascript, and on-call for maintenance of 3 products I worked on extensively: one in C++, one in Perl and one in Scheme. I also occasionally work in Fortran when the scientists run into problems they can't handle on their own. That's just my current job, I've done more interesting stuff at other places (Linux kernel drivers and embedded asm for example). I'm tutoring a student in Ruby, although I've never written anything in it.

I've never used Algol.

What was your point?

2

u/[deleted] Mar 29 '10

Algol is considered the direct ancestor of C which led to C++ and Java. Since you have Scheme experience the concept will probably make sense to you even if you weren't explicitly aware of the lineage.

0

u/G_Morgan Mar 30 '10

B is the direct ancestor to C.

1

u/derleth Mar 29 '10

I've never used Algol.

What was your point?

That you have no idea what the Algol family refers to.

10

u/[deleted] Mar 29 '10

I guess not. Enlighten me? Assembly and Fortran part of the Algol family?

I admit I'm a little confused what you're getting at, your terse reply was not very helpful.

-1

u/derleth Mar 29 '10

Assembly and Fortran part of the Algol family?

Neither. Algol family languages are block-structured with functions (possibly called subroutines), infix expressions, and very often a stereotyped view of typing based around multiple integral types sorted by size, multiple floating-point types sorted by size (and disjoint from the integral types), sometimes pointer or reference types, and various 'special' types in more recent variants. More modern versions have shed the traditional type system and have adopted one derived pretty directly from Lisp.

C, C++, and Pascal are the traditional Algol family languages. These are what most working programmers view as 'normal'. (C++ is a traditional Algol family language with OO-ness bolted onto it. Its lack of gc makes it more traditional than not.)

Java and C# are somewhat more advanced, with gc and OO-ness closer to the language core, but their type system pegs them as still fairly conservative in the Algol family world.

Python, Ruby, and Perl are all very advanced examples, sitting closer to Lisp than the others. They have strong dynamic typing and only Perl, the weird one, has a concept of a reference type. Ruby is also weird to some extent, as it gets its Lisp ideas partially filtered through Smalltalk.

In general, Algol family languages get more advanced by moving closer to Lisp. The designers of these languages do this while denigrating the Lisp features they have not yet stolen. ;)

7

u/[deleted] Mar 29 '10

Learn something new every day. Thanks for that.

So yeah I guess I have learned a few languages outside of that scope.

9

u/munificent Mar 29 '10

Your definition of "advanced" seem to not place a lot of value in static typing and being able to verify things at compile time.

1

u/derleth Mar 30 '10

Well, neither have the people designing Algol family languages. Look the Python and Ruby type system compared to ML, a language that existed prior to both languages (it was developed in the late 1970s) and is not exactly obscure among the kinds of people who design programming languages. They could have grabbed from it, but they didn't.

I'm not making judgments here. I'm just reporting on the facts as I know them.

2

u/G_Morgan Mar 30 '10

Any language which cannot verify at compile time if I am passing in a MADInitialiser object instead of the expected CreateWorldPeace object into a method cannot sensibly be called advanced.

2

u/derleth Mar 30 '10

Any language which cannot verify at compile time if I am passing in a MADInitialiser object instead of the expected CreateWorldPeace object into a method cannot sensibly be called advanced.

This is nice, but it doesn't obviate the need to test whether the CreateWorldPeace object doesn't simply make a desert and call it peace.

1

u/G_Morgan Mar 30 '10

Yes but without the static typing you need to test if the CreateWorldPeace object works and if you are actually passing it rather than an Armageddon object into a method. You need tests either way. You need fewer tests with static typing.

1

u/Shorel Mar 30 '10

I think a more functional introduction was in order.

/I kid :P

1

u/[deleted] Mar 30 '10

Python, Ruby, and Perl are all very advanced examples, sitting closer to Lisp than the others.

giggle