The Artima Developer Community
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 Paul M. Dubuc

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 54 replies on 4 pages [ « | 1 2 3 4 ]
Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: More Trouble with Programming Posted: Dec 13, 2006 4:56 AM
Reply to this message Reply
Advertisement
> Conversely, people often over-abstract, trying to design
> for problems that are largely imaginary.

Worse, by doing that they make solving real problems harder.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: More Trouble with Programming Posted: Dec 13, 2006 5:38 AM
Reply to this message Reply
> A current programming bugaboo is multithreaded
> programming. This challenges the best of the best
> programmers. We have no choice but to come up with a
> simpler, more intuitive way to do multithreaded
> programming that regular programmers can use successfully.

Have you ever wondered why humans can do such things as memory management and thread synchronization while computers can not?

This is an important question that, strangely, no one asks. From the greatest mathematicians of our time, like Wadler, to language creators like Stroustrup or yourself, to the lowly programmers like me and my buddies at work, no one have asked this simple question.

My answer to this question is that humans built the appropriate abstractions in their mind that help solve these problems, whereas compilers are not programmed to do so or there is no formalization for these abstractions.

For example, I am able to tell where an object shall be deleted in a complex C++ program, because in my mind I have formed a sequence of operations that lead to the object's deletion. This sequence of operations is not seen by the compiler.

It would be interesting to see how everybody deals with the problems like memory management and thread synchronization. Perhaps we can pinpoint the appropriate abstractions and understand that problems like thread synchronization are solvable.

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: More Trouble with Programming Posted: Dec 13, 2006 6:27 AM
Reply to this message Reply
> It would be interesting to see how everybody deals with
> the problems like memory management and thread
> synchronization. Perhaps we can pinpoint the appropriate
> abstractions and understand that problems like thread
> synchronization are solvable.

This is an interesting approach.

For memory management, it is all about scopes. I know that my object needs to live in a certain scope, and I destroy it (usually it happens automatically, via the RAII idiom) when the execution thread leaves the scope. But is it possible for a compiler to recognize the scope without a hint from the programmer?

For multithreading, I am not sure I am even able to express my reasoning :)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: More Trouble with Programming Posted: Dec 13, 2006 6:33 AM
Reply to this message Reply
> Have you ever wondered why humans can do such things as
> memory management and thread synchronization while
> computers can not?

Computers can't do anything that humans haven't told them to do. At least not yet.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: More Trouble with Programming Posted: Dec 13, 2006 7:48 AM
Reply to this message Reply
> > Have you ever wondered why humans can do such things as
> > memory management and thread synchronization while
> > computers can not?
>
> Computers can't do anything that humans haven't told them
> to do. At least not yet.


Yeah. The great thing about computers is they do exactly what you tell them to to. The terrible thing about computers is they do exactly what you tell them to do.

Bjarne Stroustrup

Posts: 60
Nickname: bjarne
Registered: Oct, 2003

Re: More Trouble with Programming Posted: Dec 13, 2006 8:23 AM
Reply to this message Reply
> > We have no choice but to come up with a
> > simpler, more intuitive way to do multithreaded
> > programming that regular programmers can use
> > successfully.
>
> Have you ever wondered why humans can do such things as
> memory management and thread synchronization while
> computers can not?
>
> This is an important question that, strangely, no one
> asks. From the greatest mathematicians of our time, like
> Wadler, to language creators like Stroustrup or yourself,
> to the lowly programmers like me and my buddies at work,
> no one have asked this simple question.

Phil Wadler? If yes, Phil is a great guy, but he is not that class of mathematician.

But yes, *many* people have asked that question in many ways. In fact, my PhD thesis was on the management of concurrency.

There is an absolutely daunting literature on the subject, but "real world users" has so far not cared and muddled along with threads.

> It would be interesting to see how everybody deals with
> the problems like memory management and thread
> synchronization. Perhaps we can pinpoint the appropriate
> abstractions and understand that problems like thread
> synchronization are solvable.

Letting lots of threads loose in a shared address space is fundamentally a bad idea. It forces users to deside where synchronization is needed and to choose which kind of synchronization is appropriate. Separating concurrent activities so that they communicate only through explicitly declared channels is key to most good solutions. I like the ideas of futures (for individual concurrent activities) and message queues (for long-running activities).

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

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: More Trouble with Programming Posted: Dec 13, 2006 9:21 AM
Reply to this message Reply
> Letting lots of threads loose in a shared address space is
> fundamentally a bad idea. It forces users to deside where
> synchronization is needed and to choose which kind of
> synchronization is appropriate. Separating concurrent
> activities so that they communicate only through
> explicitly declared channels is key to most good
> solutions. I like the ideas of futures (for individual
> concurrent activities) and message queues (for
> long-running activities).
>
> -- Bjarne Stroustrup; http://www.research.att.com/~bs

Can you recommend a good literature on these topics?

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: More Trouble with Programming Posted: Dec 13, 2006 12:41 PM
Reply to this message Reply
> > It would be interesting to see how everybody deals with
> > the problems like memory management and thread
> > synchronization. Perhaps we can pinpoint the
> appropriate
> > abstractions and understand that problems like thread
> > synchronization are solvable.
>
> Letting lots of threads loose in a shared address space is
> fundamentally a bad idea. It forces users to deside where
> synchronization is needed and to choose which kind of
> synchronization is appropriate. Separating concurrent
> activities so that they communicate only through
> explicitly declared channels is key to most good
> solutions. I like the ideas of futures (for individual
> concurrent activities) and message queues (for
> long-running activities).
>
> -- Bjarne Stroustrup; http://www.research.att.com/~bs

Thanks for replying, but I meant how everybody deals with those issues in their mind, i.e. what abstractions everyone uses in his/her brain.

It would really be interesting if some more enlightened people like you or Walter Bright or Philip Wadler can share their experiences on how they mentally map a program so as that manual memory management or synchronization is solved.

My opinion is that whatever the human brain can do, the computer can do as well, provided that the abstractions in our brains are transferred in the computer. If this can be achieved, then a great step forward would be taken: garbage collection would no longer be necessary, and more complex multithreaded programs could be written.

Paul M. Dubuc

Posts: 19
Nickname: pmd
Registered: Oct, 2004

Re: More Trouble with Programming Posted: Dec 21, 2006 5:40 AM
Reply to this message Reply
> I agree with you there. Too many times people are seduced
> into thinking the latest programming fad is a magic
> bullet. But there is steady improvement - after all, the
> vast increase in what programs do is a direct result of
> programming tools getting better.

Software development used to be a creative engineering discipline. When experienced engineers have primary responsibility for the tools, technologies and designs they use, you have a good shot at "steady improvement" in the discipline. Now throw marketing into the mix, and managers who don't understand software development, and what do you get? When software started becomming a profitable business, a product in itself instead of a means to build a product, marketing hype and the profit potential for software tools vendors started playing a larger role in those decisions. This involves convicing adopters that what they have is obsolete and that they ought to migrate to the vendor's solution. Instead of steady improvement we get "the next big thing" (which often turns out to be not so big after all) and we get people comparing what C++ was 10 years ago to what Java is now, seemingly unaware that C++ has steadily improved in the time since they abandoned it for Java.

I'm hoping that the free/open source movement has the effect of returning software development to more of a creative engineering discipline by removing some of the outrageous profit potential in marketing the "next big thing" in software development.

Paul M. Dubuc

Posts: 19
Nickname: pmd
Registered: Oct, 2004

Re: More Trouble with Programming Posted: Dec 21, 2006 5:49 AM
Reply to this message Reply
> The only way to break the vicious cycle you mention is to
> actually demand the quality - in most places where
> software is developed it is not the case; worse, they
> think that striving for the quality means lesser
> productivity.

You missed Bjarne's second point. Who's going to demand the quality if managers, or even more experienced peers, aren't even able to recognize it themselves?

Flat View: This topic has 54 replies on 4 pages [ « | 1  2  3  4 ]
Topic: CodeSynthesis XSD Release 2.3.1 - open-source XML Schema to C++ compiler Previous Topic   Next Topic Topic: Pantheios 1.0.1 full release approaching; beta 17 just released


Sponsored Links



Google
  Web Artima.com   

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