C++ Community News Forum - More Trouble with Programming

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

C++ Community News Forum
More Trouble with Programming

54 replies on 4 pages. Most recent reply: Dec 21, 2006 5:49 AM by

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 54 replies on 4 pages [ « | 1 2 3 4 | » ]

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: More Trouble with Programming

Posted: Dec 10, 2006 11:40 AM

Reply

Advertisement

> It's interesting to see a discussion about C++ drift off
> to complaints about programmer "sloppiness". The question
> rather ought to be: Does C++ support high-quality
> programming or is the needless and unfruitful complexity
> of the language an obstacle for high-quality programming?
> Is there a realistic way to reduce that complexity?

That was last week's 200+ post slugfest.

Bjarne Stroustrup

Posts: 60
Nickname: bjarne
Registered: Oct, 2003

Re: More Trouble with Programming

Posted: Dec 10, 2006 11:47 AM

Reply

> It's interesting to see a discussion about C++ drift off
> to complaints about programmer "sloppiness".

Actually, it is interesting to see how every time people ask me any question about any topic, a follow-up discussion about C++'s real and imagined failures erupt. Often, I am quite convinced that many (most, in case of /.) comments are by people who didn't bother to read the original article.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: More Trouble with Programming

Posted: Dec 10, 2006 1:01 PM

Reply

> Actually, it is interesting to see how every time people
> ask me any question about any topic, a follow-up
> discussion about C++'s real and imagined failures erupt.
> Often, I am quite convinced that many (most, in case of
> /.) comments are by people who didn't bother to read the
> original article.
>
> -- Bjarne Stroustrup; http://www.research.att.com/~bs

Maybe that just means we're all very interested in the language :)

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: More Trouble with Programming

Posted: Dec 10, 2006 1:35 PM

Reply

>
> It's interesting to see a discussion about C++ drift off
> to complaints about programmer "sloppiness".

It was my impression that the topic of the discussion was programmer sloppiness, not C++ :)

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: More Trouble with Programming

Posted: Dec 11, 2006 4:32 AM

Reply

> The only two fields I can think of where the
> same people are judge, jury and executioner are the legal
> system and programming.

Is that really true in your country? Do judges really sit in with the jury during the trial and then perform executions afterwards?

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: More Trouble with Programming

Posted: Dec 11, 2006 9:25 AM

Reply

> The problem with programming is the same problem as the
> legal system. We have the same people who both design and
> implement the system. This is wrong. Buildings have
> architects as well as contractors. They are two different
> breeds. Cars have designers and mechanics, not to mention
> drivers. The only two fields I can think of where the
> same people are judge, jury and executioner are the legal
> system and programming. It's not a coincidence that they
> both suck equally and have the same problems of
> stagnation.

I do not consider these analogies to be helpful. Architects manipulate lines in a CAD program whereas contractors move sand and steel. Car designers draw on the computer and mechanics mill the metal. The system architect writes down rules and how to organize them and the programmer also writes down rules and organizes them. There is little difference between a system architect and a programmer other than the level of abstraction they are working on. The architect decides how the megabytes are organized and the programmer about the bits and bytes. Or if you are cynical: the system architect decides everything and then the programmer does whatever he wants anyway. The closest thing the software engineering discipline has to “blueprints” is executable functional and unit tests. So maybe the system architect should just limit himself to write executable tests, an activity that happens to be, surprise, a special type of programming!

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: More Trouble with Programming

Posted: Dec 11, 2006 10:16 AM

Reply

> I do not consider these analogies to be helpful.
> Architects manipulate lines in a CAD program whereas
> contractors move sand and steel. Car designers draw on the
> computer and mechanics mill the metal. The system
> architect writes down rules and how to organize them and
> the programmer also writes down rules and organizes them.
> There is little difference between a system architect and
> a programmer other than the level of abstraction they are
> working on.

I totally agree. I was thinking that a better analogy is between the architect and a structural engineer.

There was once an article in Scientific American about the 'Falling Water' house designed by Frank Lloyd Wright. The structural engineer told Wright that he needed another support beam on one of the cantilevered patios. Wright overruled him and said it was unnecessary. So, there was a recently big project to fix the sagging patio by adding the extra beam. To me this story reminds me so much of the relationship between the 'architects' and the 'engineers' on a software project. If you have programmers that are doing mainly 'manual labor' there is a problem with the tools or the approach.

Bjarne Stroustrup

Posts: 60
Nickname: bjarne
Registered: Oct, 2003

Re: More Trouble with Programming

Posted: Dec 11, 2006 10:52 AM

Reply

> If you have
> programmers that are doing mainly 'manual labor' there is
> a problem with the tools or the approach.

Exactly. One of the problems with these analogies is that people believe them and act upon them. IMO programming is a highly skilled activity with a high intellectual component. What corresponds to "manual labor" in software development is done by compilers, build systems, etc.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: More Trouble with Programming

Posted: Dec 11, 2006 5:48 PM

Reply

> > If you have
> > programmers that are doing mainly 'manual labor' there
> is
> > a problem with the tools or the approach.
>
> Exactly. One of the problems with these analogies is that
> people believe them and act upon them. IMO programming is
> a highly skilled activity with a high intellectual
> component. What corresponds to "manual labor" in software
> development is done by compilers, build systems, etc.

I agree with the caveat that I think that repetitive activities also correspond to manual labor. While these activities cannot all be eliminated, most can. It's a continuous process and does not happen overnight and often today's solution to a repetitive task is tomorrow's repetitive task.

A lot of people clearly believe that higher-level abstractions are meant to 'dumb-down' programming. Developers that believe in this tend (in my experience) to love C++ because it gives them a lot of 'power'. My belief is the opposite. I've worked with tools that were definitely meant for unskilled people. I think this is one of the worst ideas in software history. Other highly abstracted languages do not dumb anything down at all. They allow the developer to take all thought they were putting into low-level concerns into much higher-level concerns. That is, instead of spending a lot of time building complexity into the low-level workings of a system, they can spend their time building complexity into the high-level workings of the system. When I talk about complexity, I don't mean unnecessary complexity; I mean what makes non-trivial software useful and worth writing.

I just seems to me that too many smart programmers are 'Mels' and think that if they aren't writing code at the bit level they are doing 'dumb' work. And to be bluntly honest, I think that C++ makes it too easy to get trapped on this level, especially for young programmers. I know that being forced to use a different language was what broke that spell for me.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: More Trouble with Programming

Posted: Dec 12, 2006 9:37 AM

Reply

I work at one of those "not a software companies" with 100s of programmers. We write software to support our instrumentation, but, in general, we make money selling the intruments, not the softare. One problem that arises is that nobody is paid (i.e., reviewed) on how reusable they make the code. You are reviewed on whether the SW shipped on time with the instrument. Not on whether somebody can easily use it in the next project.

On another topic.

As an old fogey who once used vi, sometimes I think the new IDEs are more of a problem than a help. I was pair programmed with an excellent, younger programmer who was studly with IDEA. After creating an initial class, we were adding standard Java code to fire events. (Sorry Bjarne, but pretend we were writing standard C++ code to fire events :-) ).

Much to my shock, he just started typing. There were a few minor missteps as he guessed the classes ("what is it, Event ListenerList???") and hit control-space, etc. to fill in the procedure names. Within a couple of minutes we had the code. I was impressed.

But his code is, of course, slightly different than every other event firing procedure in the SW. So searching, debugging, understanding are harder. (Depending on which of 3 coders wrote the code, we have 3 main ways to copy / clone / protect against listeners being added during the firing loop)

Myself, being used to older, clunkier IDEs, I would have looked for some other code that fired events, then copied and pasted it. And then, most importantly would have considered, "can we refactor this to one common codebase". (With generics you can actually do much of this)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: More Trouble with Programming

Posted: Dec 12, 2006 11:29 AM

Reply

> I work at one of those "not a software companies" with
> 100s of programmers. We write software to support our
> instrumentation, but, in general, we make money selling
> the intruments, not the softare. One problem that arises
> is that nobody is paid (i.e., reviewed) on how reusable
> they make the code. You are reviewed on whether the SW
> shipped on time with the instrument. Not on whether
> somebody can easily use it in the next project.

The way I see it, I make the code reusable so that I can continually improve my efficiency. Solving the same problem again and again means you and only increase your speed so much. This is is the kind of manual thing I am talking about.

The biggest problem with writing reusable code is that it's hard to do and most developers don't realize that. Most of the 'reusable' code I see is either not really reusable or reuse means you have to make unacceptable concessions in the new solution. You can't just use Objects and think you'll get reusable code.

> Much to my shock, he just started typing. There were a
> few minor missteps as he guessed the classes ("what is it,
> Event ListenerList???") and hit control-space, etc. to
> fill in the procedure names. Within a couple of minutes
> we had the code. I was impressed.
>
> But his code is, of course, slightly different than every
> other event firing procedure in the SW.

If it's being done again and again, you should really be creating some reusable code to do it. If it's not that common, it shouldn't really be a problem.

> Myself, being used to older, clunkier IDEs, I would have
> looked for some other code that fired events, then copied
> and pasted it. And then, most importantly would
> have considered, "can we refactor this to one common
> codebase". (With generics you can actually do much of
> this)

Well, I would chalk that up to inexperience, not the IDE. IDE's actually make it a lot easier to search the code. For example, Eclipse can search the entire code base for the use of a method, not just text that matches the method name. You should have stopped him and had him look for code that used the classes involved. This is the kind of mentoring that we need more of in this industry.

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: More Trouble with Programming

Posted: Dec 12, 2006 12:21 PM

Reply

> The biggest problem with writing reusable code is that
> it's hard to do and most developers don't realize that.
> Most of the 'reusable' code I see is either not really
> reusable or reuse means you have to make unacceptable
> concessions in the new solution. You can't just use
> Objects and think you'll get reusable code.

That often happens when someone designs a component hoping to be reusable, but they think too much of the specific context in which it will be used initially. Sometimes it's hard to think in most general terms, especially if there are tight deadlines.

Bjarne Stroustrup

Posts: 60
Nickname: bjarne
Registered: Oct, 2003

Re: More Trouble with Programming

Posted: Dec 12, 2006 12:39 PM

Reply

> > The biggest problem with writing reusable code ...
>
> ... but they think too much of the specific
> context in which it will be used initially. ...

Conversely, people often over-abstract, trying to design for problems that are largely imaginary. Good abstraction tends to come from a concrete example (or two) being generalized (without loss of clariy of preformance). Before being re-usable a piece of code has to be usable.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: More Trouble with Programming

Posted: Dec 12, 2006 12:48 PM

Reply

> > The biggest problem with writing reusable code is that
> > it's hard to do and most developers don't realize that.
> > Most of the 'reusable' code I see is either not really
> > reusable or reuse means you have to make unacceptable
> > concessions in the new solution. You can't just use
> > Objects and think you'll get reusable code.
>
> That often happens when someone designs a component hoping
> to be reusable, but they think too much of the specific
> context in which it will be used initially. Sometimes it's
> hard to think in most general terms, especially if there
> are tight deadlines.

I agree completely. I find that I can only create good reusable code if it's my second or third shot at it or if I'm reusing it at the time I write it i.e. I'm using it in at least two contexts at the initial writing. I think that usually, you shouldn't try to make it reusable until you have a second context. If you imagine you will want to reuse it, make the code clean and try not to paint yourself into a corner.

The other thing is sometimes people go overboard trying to make the reusable component fit all possible future needs. That can't be accomplished. It's better to say 'this can be reused give the follow conditions and I support these things.' Then if something more is needed, you enhance the code or don't use it for that problem. If I have 15 situations and the code is reusable in 12 of them, it still was worth it. Even if the code is only good for two real problems, it's often worth it. Sometimes it's better to take a different tack and not try to force a square peg into a round hole.

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: More Trouble with Programming

Posted: Dec 12, 2006 6:26 PM

Reply

> The other thing is sometimes people go overboard trying to
> make the reusable component fit all possible future needs.
> That can't be accomplished. It's better to say 'this can
> n be reused give the follow conditions and I support these
> things.' Then if something more is needed, you enhance
> the code or don't use it for that problem. If I have 15
> situations and the code is reusable in 12 of them, it
> still was worth it. Even if the code is only good for two
> real problems, it's often worth it. Sometimes it's better
> to take a different tack and not try to force a square peg
> into a round hole.

True, and that's pretty much inline with what dr.Stroustrup said above. This is one example where programming techniques like inheritance, forwarding and delegation come in handy. I usually use these when I have a component that's general (but not too general to make it useless) and I want to use it for some specific needs by connecting it to a more specialized component.

Flat View: This topic has 54 replies on 4 pages [ « | 1 2 3 4 | » ]

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use