The Artima Developer Community
Sponsored Link

C++ Community News Forum
The Problem with Programming

212 replies on 15 pages. Most recent reply: Dec 8, 2006 6:12 AM by James Watson

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 212 replies on 15 pages [ « | 1 ... 10 11 12 13 14 15 | » ]
James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: "No sliver bullet" is in the fine print Posted: Dec 4, 2006 6:08 AM
Reply to this message Reply
Advertisement
> > > >I would dare say that I am the first to say that
> there
> > That seems to me a lot like this:
> >
> > http://en.wikipedia.org/wiki/Perfect_solution_fallacy
>
> It may seem that way to you but you're wrong. I'm
> not rejecting anything on the basis that it isn't perfect.
> I'm suggesting that there are already many worthy choices
> and adopting something new doesn't make sense unless there
> are very significant advantages.

That's not what your post said. It said "wake me when you have a silver bullet..." The argument has been the whole time that there are very significant advantages in using something other than C++. I personally don't believe there is a perfect solution.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Problem with Programming Posted: Dec 4, 2006 6:10 AM
Reply to this message Reply
> 2) circular references is a big problem. In the software
> that I am writing, having two things linked together via a
> circular reference is the norm.

If it can't garbage collect circular references, it's pretty useless and I would also say pretty flawed.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: "No sliver bullet" is in the fine print Posted: Dec 4, 2006 7:11 AM
Reply to this message Reply
> That's not what your post said. It said "wake me when you
> have a silver bullet..." The argument has been the whole
> time that there are very significant advantages in
> using something other than C++. I personally don't
> believe there is a perfect solution.

That's very interesting given that you didn't quote that part of my argument when you first claimed I had committed a fallacy.

Nevertheless, you're still wrong. I didn't reject anything on the basis of being imperfect. My "wolf's bane" comment made it clear that I believe there are multiple imperfect "solutions" to solving programming problems.

We've reached a point, however, where improvements are getting smaller and smaller, so I believe that the argument to adopt something new is getting weaker and weaker. In my view the transition from machine/assembly language to high-level languages remains the most significant improvement and all the changes since then combined may not be as significant.

As far as C++ is concerned, it's not supposed to be the topic under discussion but since Stroustrup was interviewed, everybody with a pet language felt the need to demonstrate its superiority.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: "No sliver bullet" is in the fine print Posted: Dec 4, 2006 8:17 AM
Reply to this message Reply
> > That's not what your post said. It said "wake me when
> you
> > have a silver bullet..." The argument has been the
> whole
> > time that there are very significant advantages
> in
> > using something other than C++. I personally don't
> > believe there is a perfect solution.
>
> That's very interesting given that you didn't quote that
> part of my argument when you first claimed I had committed
> a fallacy.
>
> Nevertheless, you're still wrong. I didn't reject anything
> on the basis of being imperfect. My "wolf's bane" comment
> made it clear that I believe there are multiple imperfect
> "solutions" to solving programming problems.

Not really. This is like arguing that seat-belts aren't needed because people can just drive more carefully. If no one makes driving errors, the number of injuries from car crashes could be limited to mechanical failure (also avoidable with better mechanics and more conscientious owners) and 'acts of god' making the potential injury and death reductions provided by seat-belts and other safety features negligible.

> We've reached a point, however, where improvements are
> getting smaller and smaller, so I believe that the
> argument to adopt something new is getting weaker and
> weaker. In my view the transition from machine/assembly
> language to high-level languages remains the most
> significant improvement and all the changes since then
> combined may not be as significant.

I don't find that very convincing. I have seen major difference in productivity, robustness, reuse, and maintainability in software written in different languages.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: "No sliver bullet" is in the fine print Posted: Dec 4, 2006 8:21 AM
Reply to this message Reply
> That's very interesting given that you didn't quote that
> part of my argument when you first claimed I had committed
> a fallacy.

Actually, I never claimed you were committing a fallacy. I just stated that your argument seemed to fit a particular fallacy very well.

You are saying now that you don't think the improvements are significant. But that's not what came across in that post.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Enough language squabbling! Posted: Dec 4, 2006 4:31 PM
Reply to this message Reply
Though languages do matter, far more important is overall design, principals, and patterns. I think one huge problem is that Software Engineering now has far too many patterns and principals (and fads), many of them self-contradictory, and not enough engineers willing to cull though them to pick what makes sense for them.

Some examples:

Singletons. GoF comes out with them as a pattern, it happens to be easy to understand, so anybody with 10 fingers and a B.S. puts them all over their code. Now, several years later, we realize that they are, "good-challenged". :-)

MVC. IMO, MVC isn't evil or anything, sometimes it's needed and useful, but too many people see MVC as a design goal in itself, not as a means to an end. And it conflicts with OO principals - see nakedobjects.com and Alan Holub for counterarguments.

DiP/Spring is also, often, a good idea, but take it too far and nobpdy can figure out how anything gets done. Plus, it's not very OO.

http://www.adtmag.com/blogs/blog.aspx?a=17490


Strict typing vs. looser typing. I work in Java and still see this all the time, as half the programmers write getters and setters with strict types, e.g.

int getCount();
void setDate(Date d);

and the other half put everything into a Map and cast the results.

int count = ((Integer)getValue(Blah.COUNT)).intValue();

I favor the Map side but far more important is to pick one style and stick with it!


Passing nulls around when you really should blow up. testing for nulls and doing something "just to help out of paranoia" when you should just blow up. IMO, bad, but again, at least be consistent! I see far too much code where half the time they check for null and half the time they dont.

See the Artima discussion on Offensive Coding.
http://www.artima.com/forums/flat.jsp?forum=106&thread=168511


Arbitrary rules like "Classes should only do one thing (whatever that means) and be shorter than XXX lines". Especially combined with contradictory advice to avoid coupling (defined as # of imports). If classes get smaller, coupling must increase. Artima had a thread proposing exactly this combination of mutually exclusive goals.

Andy Dent

Posts: 165
Nickname: andydent
Registered: Nov, 2005

Re: The Problem with Programming Posted: Dec 4, 2006 6:53 PM
Reply to this message Reply
>Certainly all the apps on Mac OS X use Objective C -
>the real C with objects.

That's a fairly large exaggeration and a mischievous assertion from someone who I'm fairly certain knows better ;-)

1) some Objective-C code on the Mac is actually fronting c++ internals, using Objective-C++. Just using the Cocoa GUI doesn't mean the entire app is Objective-C.

2) I doubt if many of the top desktop apps on the Mac from major publishers are written in Objective-C - most are c++

3) Anything compiled against the Carbon libraries is using C or C++.

4) there are many alternative development platforms such as REALbasic used to produce Mac applications, especially those from smaller vendors.

Dick Ford

Posts: 149
Nickname: roybatty
Registered: Sep, 2003

Re: The Problem with Programming Posted: Dec 4, 2006 10:39 PM
Reply to this message Reply
> > > > I'm more
> > > > interested in what you think where things are going
> > and
> > > > how Smalltalk fits into that.
> > >
> > > Fine. I think the last 25 years of development have
> > been
> > > a long circuitous path towards Smalltalk.
> >
> > Handwaving gets you nowhere. Yes, new languages don't
> > usually appear in from a vacuum.
>
> You asked what I think. What handwaving? I have to prove
> what I think?

You were the one trolling Smalltalk. Let's see the evidence that Smalltalk is making some big comeback.

>
> Anyhow, I can't tell what your position is based on your
> screed.

Oh, ok, then here it is. Smalltalk isn't making a comeback.


You seem to keep changing positions while making
> ad hominem attacks.

No, just because I attacked silly fanboy handwaving doesn't mean I was changing my position.



Although you seem to be a big fan of
> Slate. I'll tell Brian when I see him. He's working for
> me just now doing - oh holy cow - Smalltalk programming.

Slate is probably a sore spot for Brian considering he drove away all potential contributors (including Lee), but didn't have the technical chops to take it any further. If you need proof, just check the irc logs.

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: "No sliver bullet" is in the fine print Posted: Dec 5, 2006 4:01 AM
Reply to this message Reply
> We've reached a point, however, where improvements are
> getting smaller and smaller, so I believe that the argument
> to adopt something new is getting weaker and weaker.

I believe that there are two aspects to this:

1) The improvements may still be large, but they tend to be more localized. There are some exceptions, such as garbage-collected environments, but most new language/platform features are narrowly focused.

2) In physics, "p = m * v" .. and our industry has a lot more "m" than it used to. The primary reason to avoid adopting new things is the cost associated with the old things (moving, maintaining, abandoning, etc.)

> As far as C++ is concerned, it's not supposed to be the
> topic under discussion but since Stroustrup was
> interviewed, everybody with a pet language felt the need
> to demonstrate its superiority.

Good point. All languages other than C++ are pet languages.

.. or perhaps some of the ideas associated with BS are controversial, and that helped to fuel a discussion.

Pick one. ;-)

Peace,

Cameron Purdy
http://www.tangosol.com/

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: "No sliver bullet" is in the fine print Posted: Dec 5, 2006 8:20 AM
Reply to this message Reply
> 1) The improvements may still be large, but they tend to
> be more localized. There are some exceptions, such as
> garbage-collected environments, but most new
> language/platform features are narrowly focused.

I guess we don't agree on the strength of the improvements. I think even the importance of GC has been exaggerated.

> Good point. All languages other than C++ are pet
> languages.
>
> .. or perhaps some of the ideas associated with BS are
> controversial, and that helped to fuel a discussion.
>
> Pick one. ;-)

You think those are the only two possibilities? I doubt that you do.

If, for example, Gosling had been interviewed on the same issue and didn't make statements suggesting that Java was better than all over langugages (it's hypothetical OK) and many people turned it into a discussion of better languages than Java, I would have said the same thing. C++ can be a pet language too.

So, I think the third possiblity is that some people saw BS's involvement as an excuse to promote their favorite language (pet or otherwise) rather than discuss what BS actually said in the interview.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: "No sliver bullet" is in the fine print Posted: Dec 5, 2006 10:03 AM
Reply to this message Reply
> So, I think the third possiblity is that some people saw
> BS's involvement as an excuse to promote their favorite
> language (pet or otherwise) rather than discuss what BS
> actually said in the interview.

I think we have been discussing what he said:


TR: In retrospect, in designing C++, wasn't your decision to
trade off programmer efficiency, security, and software
reliability for run time performance a fundamental mistake?

BS: Well, I don't think I made such a trade-off. I want
elegant and efficient code. Sometimes I get it. These
dichotomies (between efficiency versus correctness,
efficiency versus programmer time, efficiency versus
high-level, et cetera.) are bogus.


The last sentence in particular is a straw-man argument. It presumes that the only way to be efficient is to allow developers allow code that is arbitrarily unsafe. In other words he's saying that a language that provides for correctness cannot be efficient. I think that's bogus.

I think also you are misrepresenting what people (myself) at least are saying. I'm not saying Java or language X is better for everything than C++. I actually think Java has a lot of flaws. I'm fairly convinced that C++ is actually the best language at this time for certain types of applications. But that doesn't mean that there couldn't be a better language to fit that niche.

What makes software powerful is that it does certain things much better than people. Software then can augment the skills of a human that are hard to reproduce in software. I feel that C++ tries to fight the tide and let people do things that a machine can do better. Like optimization. I'll buy that sometimes you can beat everything else under the sun with C++ in certain cases... for now. But I don't think this should be the case forever. The point of having a human at the keyboard is not for bit-twiddling. Humans are slow and unreliable for that kind of task.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: "No sliver bullet" is in the fine print Posted: Dec 5, 2006 10:51 AM
Reply to this message Reply
> > So, I think the third possiblity is that some people
> saw
> > BS's involvement as an excuse to promote their favorite
> > language (pet or otherwise) rather than discuss what BS
> > actually said in the interview.
>
> I think we have been discussing what he said:
>
>

> TR: In retrospect, in designing C++, wasn't your decision
> to
> trade off programmer efficiency, security, and software
> reliability for run time performance a fundamental
> mistake?
>
> BS: Well, I don't think I made such a trade-off. I want
> elegant and efficient code. Sometimes I get it. These
> dichotomies (between efficiency versus correctness,
> efficiency versus programmer time, efficiency versus
> high-level, et cetera.) are bogus.
>

>
> The last sentence in particular is a straw-man argument.
> It presumes that the only way to be efficient is to allow
> w developers allow code that is arbitrarily unsafe. In
> other words he's saying that a language that provides for
> correctness cannot be efficient. I think that's bogus.
>

That's not what he's saying at all. What he is saying is that C++ allows for efficiency, security and reliability as well as runtime performance. He said the dichoctomy of efficiency vs. correctness is bogus. That would mean he believes both are possible at the same time. So you agree with him. A lot of people believe C++ allows for correctness. What it doesn't do is enforce it in any way, which is what makes people grumpy.

> I think also you are misrepresenting what people (myself)
> at least are saying. I'm not saying Java or language X is
> better for everything than C++. I actually think Java has
> a lot of flaws. I'm fairly convinced that C++ is actually
> the best language at this time for certain types of
> applications. But that doesn't mean that there couldn't
> be a better language to fit that niche.
>

I think D is worth a look if anybody were to seriously consider a different systems programming language. It's garbage collected, has RAII and allows you explicit memory allocation. It's got thread synchronization primitives, built in strings, associative arrays and resizeable arrays.

It has a lot of good ideas, but seems to go in bursts as far as development goes. GNU has a front end for D for gcc, so it's gotta have some traction out there. Either that or somebody was really, really bored.

> What makes software powerful is that it does certain
> things much better than people. Software then can augment
> the skills of a human that are hard to reproduce in
> software. I feel that C++ tries to fight the tide and let
> people do things that a machine can do better. Like
> optimization. I'll buy that sometimes you can beat
> everything else under the sun with C++ in certain cases...
> for now. But I don't think this should be the case
> forever. The point of having a human at the keyboard is
> not for bit-twiddling. Humans are slow and unreliable for
> that kind of task.

I don't think C++ fights the tide as hard as some people here have represented. Besides, all those algorithms in java, C#, etc. had to be written by somebody anyway. JITs don't write themselves. At some point there is a person responsible. I think most people that use C++ are perfectly happy deferring to the compiler and standard library as much as possible. I know I am. In some cases what is provided isn't good enough, however, and C++ gives you the power to do what you need to do in order to get the job done. Java and its ilk close off some areas to the application developer. In most cases that isn't a big deal. In some cases it is.

The point of having a human at the keyboard is to solve a human problem. In some cases that does require bit twiddling. I don't know if that will always be the case but given that people design the machines and compilers I expect this to be the case at least for the duration of my life. Besides, some of us find bit-twiddlng to be fun in its own right :-)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: "No sliver bullet" is in the fine print Posted: Dec 5, 2006 12:06 PM
Reply to this message Reply
> That's not what he's saying at all. What he is saying is
> that C++ allows for efficiency, security and reliability
> as well as runtime performance. He said the dichoctomy of
> efficiency vs. correctness is bogus. That would mean he
> believes both are possible at the same time. So you agree
> with him. A lot of people believe C++ allows for
> correctness. What it doesn't do is enforce it in any way,
> which is what makes people grumpy.

C++ allows for correctness; it doesn't enforce it. That's the point. His answer is that C++ doesn't stop you from writing correct code. My car doesn't force me to get into an accident. That's a much different statement then saying my car prevents me from getting into accidents. The reality is that C++ doesn't do much of anything to prevent error. If runtime efficiency isn't the reason, what is the reason?

> > I think also you are misrepresenting what people
> (myself)
> > at least are saying. I'm not saying Java or language X
> is
> > better for everything than C++. I actually think Java
> has
> > a lot of flaws. I'm fairly convinced that C++ is
> actually
> > the best language at this time for certain types of
> > applications. But that doesn't mean that there
> couldn't
> > be a better language to fit that niche.
> >
>
> I think D is worth a look if anybody were to seriously
> consider a different systems programming language. It's
> garbage collected, has RAII and allows you explicit memory
> allocation. It's got thread synchronization primitives,
> built in strings, associative arrays and resizeable
> arrays.
>
> It has a lot of good ideas, but seems to go in bursts as
> far as development goes. GNU has a front end for D for
> gcc, so it's gotta have some traction out there. Either
> that or somebody was really, really bored.
>
> > What makes software powerful is that it does certain
> > things much better than people. Software then can
> augment
> > the skills of a human that are hard to reproduce in
> > software. I feel that C++ tries to fight the tide and
> let
> > people do things that a machine can do better. Like
> > optimization. I'll buy that sometimes you can beat
> > everything else under the sun with C++ in certain
> cases...
> > for now. But I don't think this should be the case
> > forever. The point of having a human at the keyboard
> is
> > not for bit-twiddling. Humans are slow and unreliable
> for
> > that kind of task.
>
> I don't think C++ fights the tide as hard as some people
> here have represented. Besides, all those algorithms in
> java, C#, etc. had to be written by somebody anyway. JITs
> don't write themselves.

And somehow this means we must use C++ to write them?

And the first C++ compiler had to be written in another language. All advancements in languages have been built upon a previous abstraction.

> At some point there is a person
> responsible.

Someone at some point had to write machine code by hand. This doesn't everyone should.

> I think most people that use C++ are
> perfectly happy deferring to the compiler and standard
> library as much as possible. I know I am. In some cases
> what is provided isn't good enough, however, and C++ gives
> you the power to do what you need to do in order to get
> the job done.

No other language but C++ allows for this and no such other language is possible?

> Java and its ilk close off some areas to the
> application developer. In most cases that isn't a big
> deal. In some cases it is.

You forgot to mention the price of tea in China.

> The point of having a human at the keyboard is to solve a
> human problem. In some cases that does require bit
> twiddling.

I think that's a the very least an unproven assertion.

> I don't know if that will always be the case
> but given that people design the machines and compilers I
> expect this to be the case at least for the duration of my
> life. Besides, some of us find bit-twiddlng to be fun in
> its own right :-)

And that last statement is really why I think people cling to C++. They like being down in the weeds. I've written machine code and assembler. I felt a sense of great achievement when I worked it out. There may be times when someone needs to go back to those levels to start over. But this is the exception. It's highly inefficient in terms of programmer time and it's not special. It's not what the art of programming is about. It's menial.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: "No sliver bullet" is in the fine print Posted: Dec 5, 2006 1:36 PM
Reply to this message Reply
> C++ allows for correctness; it doesn't enforce it. That's
> the point. His answer is that C++ doesn't stop you from
> writing correct code. My car doesn't force me to get into
> an accident. That's a much different statement then
> saying my car prevents me from getting into accidents.
> The reality is that C++ doesn't do much of anything to
> o prevent error. If runtime efficiency isn't the reason,
> what is the reason?

Runtime efficiency is one reason. This actually matters to some people. Another, to me, is correctly modeling the problem domain. Every system in the world isn't an object and for some problems a strict or nearly strict OO language such as java is more of a handicap than a help. You make it sound as if it is impossible to write elegant "correct" code in C++. To that I say bullocks. Is it harder? In some cases, yes. Besides, when you come down to it "correctness" is nothing more than opinion and, if we're lucky, a consensus opinion.

Modern C++ goes a long way toward helping people not make common errors. Everybody bitches and moans about managing memory as a big deal and the fact of the matter is you don't need to do low level memory management in C++ in the vast majority of cases. You don't have to use raw C arrays, either. The STL provides containers that are efficient and safe. I find C++'s mechanisms as good as or better than most languages, but we've had that discussion already. You don't agree and that's fine.



> And somehow this means we must use C++ to write them?

No. D is an option I mentioned. It has a lot of the features of java you appear to like and most of the raw power of C++. I don't ever remember saying that C++ is what everything should be written in. You seem to have ignored that.

My point was simply that many people's bias against C++ amounts to prejudice. Most of people's gripes with C++ are unfounded or, at best, on shaky ground. Also, I think there is a trend away from lowlevel systems programming and people understanding how computers work. At least this is what I've seen in my experience. If everybody keeps working at higher and higher level of abstraction, who in the world is going to write all the nice memory managed virtual runtimes that applications should be run in.

I can't find the blog, but there was a microsoft blog I read a few weeks ago where somebody was lamenting about how hard it was to find "good developers". They were looking for the sort of people that could actually write the garbage collector for .NET or java. Everybody seems so focused on abstracting everything away that the knowledge of how things actually work under the covers is becoming the domain of a shrinking group. I find this alarming at best. On the plus side, I seem to be pretty valuable to the people I work for because I can find and fix problems that a lot of people seem to have trouble finding simply because they can't imagine how their code could be so slow. The runtime should just automagically make everything fast for them.

>
> And the first C++ compiler had to be written in another
> language. All advancements in languages have been built
> upon a previous abstraction.
>

I'm sure that trend will continue. In many cases it is the right choice. That being said there are many people that dip down into assembler to get things done. I don't disagree with you, but sometimes you need to get as close to the metal as possible. Environments like java and .NET completely remove that option.

> > At some point there is a person
> > responsible.
>
> Someone at some point had to write machine code by hand.
> This doesn't everyone should.

Again, I don't disagree with that. But if I have to get down to that level it's nice to know I can.

>
> > I think most people that use C++ are
> > perfectly happy deferring to the compiler and standard
> > library as much as possible. I know I am. In some cases
> > what is provided isn't good enough, however, and C++
> gives
> > you the power to do what you need to do in order to get
> > the job done.
>
> No other language but C++ allows for this and no such
> other language is possible?
>

I'll say take a look at D again. But, to be honest, right now, no widespread language has the combination of raw power and high level of abstraction that C++ does. This is both its blessing and its curse, as this thread has made amply clear. Many languages have better high level abstractions than C++. C and assembly might let you write more memory and CPU efficient code if you try real hard. C++ (warts and all) combines the two pretty well.

> > Java and its ilk close off some areas to the
> > application developer. In most cases that isn't a big
> > deal. In some cases it is.
>
> You forgot to mention the price of tea in China.
>

Also the prices of lemons in london.

> > The point of having a human at the keyboard is to solve
> a
> > human problem. In some cases that does require bit
> > twiddling.
>
> I think that's a the very least an unproven assertion.

Really? The reason I write code every day is to help solve some problem somebody has. If nobody needed the computer to actually do anything, I wouldn't have a job. Sometimes I twiddle bits to make that happen. So at best my assertion is anecdotal. You mentioned that the point of having a human at the keyboard is not bit-twiddling. What do you think the point is, then?

>
> > I don't know if that will always be the case
> > but given that people design the machines and compilers
> I
> > expect this to be the case at least for the duration of
> my
> > life. Besides, some of us find bit-twiddlng to be fun
> in
> > its own right :-)
>
> And that last statement is really why I think people cling
> to C++. They like being down in the weeds. I've written
> machine code and assembler. I felt a sense of great
> achievement when I worked it out. There may be times when
> someone needs to go back to those levels to start over.
> But this is the exception. It's highly inefficient in
> n terms of programmer time and it's not special. It's not
> what the art of programming is about. It's menial.

I agree that dropping down to that low level of abstraction should be the exception but I think you are very wrong about that being the reason people cling to C++. I don't like regularly getting down into the weeds. But I really like the option. People cling to it because they have the option. People that write games and rendering engines drop down to this level quite often. I consider the work they do very special. If that is menial, is a class that manages database connections really even worth mentioning?

So what is the art of programming about to you?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: "No sliver bullet" is in the fine print Posted: Dec 6, 2006 6:31 AM
Reply to this message Reply
> Really? The reason I write code every day is to help solve
> some problem somebody has. If nobody needed the computer
> to actually do anything, I wouldn't have a job. Sometimes
> I twiddle bits to make that happen. So at best my
> assertion is anecdotal. You mentioned that the point of
> having a human at the keyboard is not bit-twiddling. What
> do you think the point is, then?

To create complex requirements and to translate those requirements into properly working software.

> >
> > > I don't know if that will always be the case
> > > but given that people design the machines and
> compilers
> > I
> > > expect this to be the case at least for the duration
> of
> > my
> > > life. Besides, some of us find bit-twiddlng to be fun
> > in
> > > its own right :-)
> >
> > And that last statement is really why I think people
> cling
> > to C++. They like being down in the weeds. I've
> written
> > machine code and assembler. I felt a sense of great
> > achievement when I worked it out. There may be times
> when
> > someone needs to go back to those levels to start over.
> > But this is the exception. It's highly inefficient in
> > n terms of programmer time and it's not special. It's
> not
> > what the art of programming is about. It's menial.
>
> I agree that dropping down to that low level of
> abstraction should be the exception but I think you are
> very wrong about that being the reason people cling to
> C++. I don't like regularly getting down into the weeds.
> But I really like the option. People cling to it because
> they have the option. People that write games and
> rendering engines drop down to this level quite often. I
> consider the work they do very special. If that is menial,
> is a class that manages database connections really even
> worth mentioning?
>
> So what is the art of programming about to you?

I find it highly unlikely that everyone writing code in C++ has to drop down into the weeds to do something fundamentally different from what every other developer in a similar situation has ever done. I wrote this class to handle database connections because every Java developer that uses the JDBC libraries ends up writing the same basic boilerplate code again and again and often incorrectly. I'm working with a team of COBOL and RPG developers and I don't want to go through all the errors that are surely to occur again. In other words, I created a design (not menial) to take care of a repetitive task that is menial.

If someone needs to drop down to a lower level abstraction, it's not a sign that the language is great. It's a sign that something is missing. Python, allows bit-twiddling in C but this is only done when you need to fill in a gap. The average Python developer will never need to do this and probably shouldn't.

The problem I see with all this power that C++ gives you is that a lot of people get off on it. I can't count the number of times I've seen people write the most cockamamie crap in the name of optimization. Some of the time, the effect is actually negative, most of the time, it has no detectable effect on performance and most of the rest of the time, the effect isn't worth the effort or the cancerous effect it has on the code base.

The art of programming, in my mind, is really design in action. Programming languages are becoming really powerful syntaxes for expressing processes and not just mnemonics for micromanaging the hardware.

I think C++ has it's place. It's just not as the primary development tool for most software. It's vastly overused.

Flat View: This topic has 212 replies on 15 pages [ « | 10  11  12  13  14  15 | » ]
Topic: Pantheios 1.0.1 full release approaching; beta 17 just released Previous Topic   Next Topic Topic: John Ousterhout on What Limits Software Growth

Sponsored Links



Google
  Web Artima.com   

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