C++ Community News Forum - The Problem with Programming

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

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

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 212 replies on 15 pages [ « | 1 ... 11 12 13 14 15 | » ]

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: "No sliver bullet" is in the fine print

Posted: Dec 6, 2006 7:39 AM

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

That sounds like the same thing I said, but it uses a lot more syllables. Personally I like to make the requirements as simple as possible but alas, as simple as possible isn't always simple :-(

>
> 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.
>

I don't doubt that, but to call bit-twiddling in and of itself menial is a gross generalization. Many great pieces of software require bit twiddling and wouldn't be able to meet requirements in any other way.

> 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.

I don't see how that signifies something is missing. Maybe lower level of abstraction was the wrong phrase. In some instances you have to reduce the number of instructions executed or do something clever to get the same result in a more efficient manner. Bit shifting to divide by 2 and Duff's Device are probably the two most well known instances of this. I don't understand how a higher level of abstraction will get you the required performance improvements in cases like that.

> Python, allows
> s 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.
>

In my opinion use of C++ should be approached the same way as how you present the Python/C combo. I think the fact that the language allows both approaches is a benefit, not a detriment. Python is the language I use at home for a lot of things and I've never dropped down to do C bit twiddling. In the couple of cases I've had to I've just done the whole program in C++ (none of the projects were very big) because I had access to both types of programming and did not have to switch development environments, runtimes or modes of thought.

> 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.
>

I don't see this as being a problem with the language. I see this as a problem with the person using the language. I would rather have the freedom to do what I want than to have the language restrict me, much in the same way I would rather let somebody say something that I find offensive than to have my own speech restricted.

> The art of programming, in my mind, is really design in
> action.

That sounds like it belongs in a book somewhere. :-)

> Programming languages are becoming really
> powerful syntaxes for expressing processes and not just
> mnemonics for micromanaging the hardware.
>

Basically you just said that programming languages are becoming lisp, which was invented as a notation for describing computations, not as a programming language per se, which is probably why it has survived in a relatively unaltered state for about half a century. Sounds very Paul Graham to me.

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

I would say that it is vastly misused if what you describe as the current state of the use of C++ is true. I don't think most people grossly misuse the language in the way you imagine. Most uses of it that I am familiar with are at a pretty high level and take full advantage of templates and objects and don't have any of the low level abominations you seem so afraid of.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: "No sliver bullet" is in the fine print

Posted: Dec 6, 2006 10:32 AM

> 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 didn't respond to this before but I think this is really the problem. You assume that higher levels of abstraction means 'dumb'. It's the exact opposite. Building high levels of abstraction is what we do. As an analogy, when most adults walk, they do not think about flexing each muscle involved at the right moments in time.

I'm not saying that no one should be able to do these things or that they shouldn't be done. I'm saying that 1. Most development doesn't need this and a lot of developers that think they need it don't. 2. C++ is a rummage-bin of features, the vast majority of which are just not needed. There's got to be possible to have a better language than that.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: "No sliver bullet" is in the fine print

Posted: Dec 6, 2006 10:51 AM

> > To create complex requirements and to translate those
> > requirements into properly working software.
>
> That sounds like the same thing I said, but it uses a lot
> more syllables. Personally I like to make the requirements
> as simple as possible but alas, as simple as possible
> isn't always simple :-(

I don't know what that has to do with what I am saying.

> I don't doubt that, but to call bit-twiddling in and of
> itself menial is a gross generalization. Many great pieces
> of software require bit twiddling and wouldn't be able to
> meet requirements in any other way.

That's clearly your assumption, yes.

> > 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.
>
> I don't see how that signifies something is missing. Maybe
> lower level of abstraction was the wrong phrase. In some
> instances you have to reduce the number of instructions
> executed or do something clever to get the same result in
> a more efficient manner. Bit shifting to divide by 2 and
> Duff's Device are probably the two most well known
> instances of this. I don't understand how a higher level
> of abstraction will get you the required performance
> improvements in cases like that.

Why do you think these optimizations have to be made a human?

> > Python, allows
> > s 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.
> >
>
> In my opinion use of C++ should be approached the same way
> as how you present the Python/C combo.

Should is the key word here. That's all well and good if you develop by yourself in a vacuum. I don't.

> I think the fact
> that the language allows both approaches is a benefit, not
> a detriment.

You are missing the point. C++ sucks compared to a lot of languages for the higher abstractions. It's ugly, inelegant and overcomplicated. To use it in team development without major maintenance issues you need to restrict the syntax to a small subset of what is available. That in itself is costly and inefficient.

> Python is the language I use at home for a
> lot of things and I've never dropped down to do C bit
> twiddling. In the couple of cases I've had to I've just
> done the whole program in C++ (none of the projects were
> very big) because I had access to both types of
> programming and did not have to switch development
> environments, runtimes or modes of thought.

Why not take what you needed at the low level and make it reusable for yourself and others in Python?

> > 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.
> >
>
> I don't see this as being a problem with the language. I
> see this as a problem with the person using the language.
> I would rather have the freedom to do what I want than to
> have the language restrict me, much in the same way I
> would rather let somebody say something that I find
> offensive than to have my own speech restricted.

I used to think like that. Then I found out there is a lot more freedom in not having to think about all that and just getting stuff done.

> Basically you just said that programming languages are
> becoming lisp, which was invented as a notation for
> describing computations, not as a programming language per
> se, which is probably why it has survived in a relatively
> unaltered state for about half a century. Sounds very Paul
> Graham to me.

Lisp is a very narrow approach to the problem. I also think it's a kind-of a cop out. It seems kind of like it was designed to be easy for the person writing the parser, not the person using it.

> > I think C++ has it's place. It's just not as the
> primary
> > development tool for most software. It's vastly
> overused.
>
> I would say that it is vastly misused if what you describe
> as the current state of the use of C++ is true. I don't
> think most people grossly misuse the language in the way
> you imagine.

Really? You think that all the C++ jobs out there are for working on projects that require writing system level code? I'd say it's probably a lot of teams that need people to help keep their homemade GUI from falling down or similar things.

> Most uses of it that I am familiar with are
> at a pretty high level and take full advantage of
> templates and objects and don't have any of the low level
> abominations you seem so afraid of.

So why use a language that is so punishing if you don't need the low-level stuff. Personally I don't think much of templates in C++ either. It's the most effective obfuscation tool I've ever seen. It's the kind of thing that bugs me about C++. Instead of coming up with clean designs, developers use a bunch of fancy tricks.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: "No sliver bullet" is in the fine print

Posted: Dec 6, 2006 10:59 AM

> don't have any of the low level
> abominations you seem so afraid of.

BTW: I'm not afraid of them. I don't know if you are just not following or are purpose attempting to grossly misrepresent what I am saying.

Let me ask you a question. Do you use sporks on a regular basis?

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: "No sliver bullet" is in the fine print

Posted: Dec 6, 2006 5:14 PM

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

I said it's about solving problems. This sounds a lot like solving problems. The complexity part is usually unnecessarily human generated.

> > That sounds like the same thing I said, but it uses a
> lot
> > more syllables. Personally I like to make the
> requirements
> > as simple as possible but alas, as simple as possible
> > isn't always simple :-(
>
> I don't know what that has to do with what I am saying.

You mentioned complex. I've seen plenty of systems where complexity is written in that doesn't need to be there. Sometimes system really are complex. Most of the time a simple problem is over architected. I don't know where you fall in this continuum. I'll be optimistic and assume like you like simple when possible.

>
> > I don't doubt that, but to call bit-twiddling in and of
> > itself menial is a gross generalization. Many great
> pieces
> > of software require bit twiddling and wouldn't be able
> to
> > meet requirements in any other way.
>
> That's clearly your assumption, yes.
>

It's an assumption based on personal experience. You can doubt it if you want. You are entitled to your opinion, flawed though it may be.

> > > 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.
> >
> > I don't see how that signifies something is missing.
> Maybe
> > lower level of abstraction was the wrong phrase. In
> some
> > instances you have to reduce the number of instructions
> > executed or do something clever to get the same result
> in
> > a more efficient manner. Bit shifting to divide by 2
> and
> > Duff's Device are probably the two most well known
> > instances of this. I don't understand how a higher
> level
> > of abstraction will get you the required performance
> > improvements in cases like that.
>
> Why do you think these optimizations have to be made a
> human?
>

If the compiler or runtime environment has limitations, who else is going to do them? I don't doubt that in most cases the runtime or compiler does a great job, but sometimes there are limitations. Compilers and runtimes need to be written to the general case. In many instances a much more optimal solution can be written to solve your particular problem. That would be the difference between theorizing about how to solve a problem and actually solving it.

> > > Python, allows
> > > s 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.
> > >
> >
> > In my opinion use of C++ should be approached the same
> way
> > as how you present the Python/C combo.
>
> Should is the key word here. That's all well and good if
> you develop by yourself in a vacuum. I don't.
>

I don't either.

> > I think the fact
> > that the language allows both approaches is a benefit,
> not
> > a detriment.
>
> You are missing the point. C++ sucks compared to a lot of
> languages for the higher abstractions. It's ugly,
> inelegant and overcomplicated. To use it in team
> development without major maintenance issues you need to
> restrict the syntax to a small subset of what is
> available. That in itself is costly and inefficient.
>

That is your opinion. I disagree. I've seen plenty of C++ that would be mistaken for your beloved java.

> > Python is the language I use at home for a
> > lot of things and I've never dropped down to do C bit
> > twiddling. In the couple of cases I've had to I've just
> > done the whole program in C++ (none of the projects
> were
> > very big) because I had access to both types of
> > programming and did not have to switch development
> > environments, runtimes or modes of thought.
>
> Why not take what you needed at the low level and make it
> reusable for yourself and others in Python?
>

I can reuse the C++ if I want or need to. From python if I'm so inclined. I work better coding the whole initial solution in one place. That's just how I work.

> > > 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.
> > >
> >
> > I don't see this as being a problem with the language.
> I
> > see this as a problem with the person using the
> language.
> > I would rather have the freedom to do what I want than
> to
> > have the language restrict me, much in the same way I
> > would rather let somebody say something that I find
> > offensive than to have my own speech restricted.
>
> I used to think like that. Then I found out there is a
> lot more freedom in not having to think about all that and
> just getting stuff done.
>

I've had to clean up great swaths of code generated by people with that mindset. Good to know job security won't be a problem for me.

> > Basically you just said that programming languages are
> > becoming lisp, which was invented as a notation for
> > describing computations, not as a programming language
> per
> > se, which is probably why it has survived in a
> relatively
> > unaltered state for about half a century. Sounds very
> Paul
> > Graham to me.
>
> Lisp is a very narrow approach to the problem. I also
> think it's a kind-of a cop out. It seems kind of like it
> was designed to be easy for the person writing the parser,
> not the person using it.
>

You can read about why LISP was designed the way it was instead of guessing. You said "Programming languages are becoming really powerful syntaxes for expressing processes and not just mnemonics for micromanaging the hardware." That's a pretty fair summary of what McCarthy says here http://www-formal.stanford.edu/jmc/recursive/recursive.html

> > > I think C++ has it's place. It's just not as the
> > primary
> > > development tool for most software. It's vastly
> > overused.
> >
> > I would say that it is vastly misused if what you
> describe
> > as the current state of the use of C++ is true. I don't
> > think most people grossly misuse the language in the
> way
> > you imagine.
>
> Really? You think that all the C++ jobs out there are for
> working on projects that require writing system level
> code? I'd say it's probably a lot of teams that need
> people to help keep their homemade GUI from falling down
> or similar things.
>

I can quote somebody I know to answer this one "That's clearly your assumption, yes."

> > Most uses of it that I am familiar with are
> > at a pretty high level and take full advantage of
> > templates and objects and don't have any of the low
> level
> > abominations you seem so afraid of.
>
> So why use a language that is so punishing if you don't
> need the low-level stuff. Personally I don't think much
> of templates in C++ either. It's the most effective
> obfuscation tool I've ever seen. It's the kind of thing
> that bugs me about C++. Instead of coming up with clean
> designs, developers use a bunch of fancy tricks.

A lot of us don't find C++ punishing. Really. Intricate, complex, sometimes difficult, yes. But not punishing.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: "No sliver bullet" is in the fine print

Posted: Dec 6, 2006 5:17 PM

> > don't have any of the low level
> > abominations you seem so afraid of.
>
> BTW: I'm not afraid of them. I don't know if you are just
> not following or are purpose attempting to grossly
> misrepresent what I am saying.
>
> Let me ask you a question. Do you use sporks on a regular
> basis?

C++ is more like having the entire set of flatware and only taking the pieces you need. For example, if I'm having desert, I can take the desert fork and be done with it. I don't need to grab the knife and the dinner fork and the soup spoon. Complex, I know, but I can handle it. A spork is a one size fits all solution. You have to have the spoon and the fork whether you want them or not. Kind of like carrying around a virtual machine and large runtime library.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: "No sliver bullet" is in the fine print

Posted: Dec 6, 2006 5:39 PM

> > 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 didn't respond to this before but I think this is really
> the problem. You assume that higher levels of abstraction
> means 'dumb'. It's the exact opposite. Building high
> levels of abstraction is what we do. As an analogy, when
> most adults walk, they do not think about flexing each
> muscle involved at the right moments in time.
>

I would call it ignorant. If you are being willfully ignorant then I would say dumb. If abstractions never leaked I'd be in 100% agreement with you. The simple fact is they do and when they do you need to fix it if there is a problem. I've worked with people that don't have a clue about this stuff and with the amount of effort required to explain simple things to them like why the need a StringBuilder instead of a string, you'd think I was explaining some sort of black magic to them.

> I'm not saying that no one should be able to do these
> things or that they shouldn't be done. I'm saying that 1.
> Most development doesn't need this and a lot of developers
> that think they need it don't.

I've not worked with these developers. The ones that I work with that know C++ seem to regularly work at a good level of abstraction without resorting to "tricks".

> 2. C++ is a rummage-bin
> of features, the vast majority of which are just not
> needed. There's got to be possible to have a better
> language than that.

I'd call it a chest of drawers. You can take what you need and leave the rest behind.

I heard once that language design was the art of removing what you didn't think you needed in C++ and then slowly adding it back in as you realized you were wrong. I don't know how true that is, but with the recent additions to C# and java, a case could be made for that statement being true.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: "No sliver bullet" is in the fine print

Posted: Dec 6, 2006 5:44 PM

> > > > To create complex requirements and to translate
> those
> > > > requirements into properly working software.
> > >
>
> I said it's about solving problems. This sounds a lot like
> solving problems. The complexity part is usually
> unnecessarily human generated.

'Solving problems' includes fixing a flat tire.

> > > That sounds like the same thing I said, but it uses a
> > lot
> > > more syllables. Personally I like to make the
> > requirements
> > > as simple as possible but alas, as simple as possible
> > > isn't always simple :-(
> >
> > I don't know what that has to do with what I am saying.
>
> You mentioned complex. I've seen plenty of systems where
> complexity is written in that doesn't need to be there.
> Sometimes system really are complex. Most of the time a
> simple problem is over architected. I don't know where you
> fall in this continuum. I'll be optimistic and assume like
> you like simple when possible.

You didn't get the point then. The work I do is to automate complicated processes. Usually they are vastly more complex than they may seem from a distance. Multiplying a number by 2 faster is not important in this context. It's kind of banal.

> >
> > > I don't doubt that, but to call bit-twiddling in and
> of
> > > itself menial is a gross generalization. Many great
> > pieces
> > > of software require bit twiddling and wouldn't be
> able
> > to
> > > meet requirements in any other way.
> >
> > That's clearly your assumption, yes.
> >
>
> It's an assumption based on personal experience. You can
> doubt it if you want. You are entitled to your opinion,
> flawed though it may be.

Sorry, I forgot that you hold all the knowledge of the universe and know of every possible approach to a given problem.

I know it's hard to believe that your skills could become obsolete but I see it all the time. The COBOL and RPG developers I work with are always sure there is no better way.

> > > > 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.
> > >
> > > I don't see how that signifies something is missing.
> > Maybe
> > > lower level of abstraction was the wrong phrase. In
> > some
> > > instances you have to reduce the number of
> instructions
> > > executed or do something clever to get the same
> result
> > in
> > > a more efficient manner. Bit shifting to divide by 2
> > and
> > > Duff's Device are probably the two most well known
> > > instances of this. I don't understand how a higher
> > level
> > > of abstraction will get you the required performance
> > > improvements in cases like that.
> >
> > Why do you think these optimizations have to be made a
> > human?
> >
>
> If the compiler or runtime environment has limitations,
> who else is going to do them?

I never mentioned a runtime or an environment. What about a compiler?

> I don't doubt that in most
> cases the runtime or compiler does a great job, but
> sometimes there are limitations. Compilers and runtimes
> need to be written to the general case. In many instances
> a much more optimal solution can be written to solve your
> particular problem. That would be the difference between
> theorizing about how to solve a problem and actually
> solving it.

Whatever. Developers said the same thing when the first high-level languages came out.

> You are missing the point. C++ sucks compared to a lot
> of
> > languages for the higher abstractions. It's ugly,
> > inelegant and overcomplicated. To use it in team
> > development without major maintenance issues you need
> to
> > restrict the syntax to a small subset of what is
> > available. That in itself is costly and inefficient.
> >
>
> That is your opinion. I disagree. I've seen plenty of C++
> that would be mistaken for your beloved java.

We aren't talking about Java and I don't know how many times I have to say that I think it's got a lot of problems. In any event, if that's the case, the developers restricted 'the syntax to a small subset of what is available' so it seems like a poor way to argue that I am wrong.

> > > Python is the language I use at home for a
> > > lot of things and I've never dropped down to do C bit
> > > twiddling. In the couple of cases I've had to I've
> just
> > > done the whole program in C++ (none of the projects
> > were
> > > very big) because I had access to both types of
> > > programming and did not have to switch development
> > > environments, runtimes or modes of thought.
> >
> > Why not take what you needed at the low level and make
> it
> > reusable for yourself and others in Python?
> >
>
> I can reuse the C++ if I want or need to. From python if
> I'm so inclined. I work better coding the whole initial
> solution in one place. That's just how I work.

Seems like a limitation to me.

> > > > 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.
> > > >
> > >
> > > I don't see this as being a problem with the
> language.
> > I
> > > see this as a problem with the person using the
> > language.
> > > I would rather have the freedom to do what I want
> than
> > to
> > > have the language restrict me, much in the same way I
> > > would rather let somebody say something that I find
> > > offensive than to have my own speech restricted.
> >
> > I used to think like that. Then I found out there is a
> > lot more freedom in not having to think about all that
> and
> > just getting stuff done.
> >
>
> I've had to clean up great swaths of code generated by
> people with that mindset. Good to know job security won't
> be a problem for me.

And I've fixed uncountable numbers of bugs written be people with your mindset.

> > > Basically you just said that programming languages
> are
> > > becoming lisp, which was invented as a notation for
> > > describing computations, not as a programming
> language
> > per
> > > se, which is probably why it has survived in a
> > relatively
> > > unaltered state for about half a century. Sounds very
> > Paul
> > > Graham to me.
> >
> > Lisp is a very narrow approach to the problem. I also
> > think it's a kind-of a cop out. It seems kind of like
> it
> > was designed to be easy for the person writing the
> parser,
> > not the person using it.
> >
>
> You can read about why LISP was designed the way it was
> instead of guessing. You said "Programming languages are
> becoming really powerful syntaxes for expressing processes
> and not just mnemonics for micromanaging the hardware."
> That's a pretty fair summary of what McCarthy says here

And from that you make the leap that I'm talking about LISP. That's pretty illogical.

> > > > I think C++ has it's place. It's just not as the
> > > primary
> > > > development tool for most software. It's vastly
> > > overused.
> > >
> > > I would say that it is vastly misused if what you
> > describe
> > > as the current state of the use of C++ is true. I
> don't
> > > think most people grossly misuse the language in the
> > way
> > > you imagine.
> >
> > Really? You think that all the C++ jobs out there are
> for
> > working on projects that require writing system level
> > code? I'd say it's probably a lot of teams that
> need
> > people to help keep their homemade GUI from falling
> down
> > or similar things.
> >
>
> I can quote somebody I know to answer this one "That's
> clearly your assumption, yes."

I never stated it as if it were a fact, did I?

> > So why use a language that is so punishing if you don't
> > need the low-level stuff. Personally I don't think
> much
> > of templates in C++ either. It's the most effective
> > obfuscation tool I've ever seen. It's the kind of
> thing
> > that bugs me about C++. Instead of coming up with
> clean
> > designs, developers use a bunch of fancy tricks.
>
> A lot of us don't find C++ punishing. Really. Intricate,
> complex, sometimes difficult, yes. But not punishing.

Yes a wonderful tool. Intricate, difficult and complex, who could ask for more in a tool. But that's what you like about it, right? It's a macho thing.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: "No sliver bullet" is in the fine print

Posted: Dec 6, 2006 6:01 PM

> > > > > To create complex requirements and to translate
> > those
> > > > > requirements into properly working software.
> > > >
> >
> > I said it's about solving problems. This sounds a lot
> like
> > solving problems. The complexity part is usually
> > unnecessarily human generated.
>
> 'Solving problems' includes fixing a flat tire.

True.

>
> > > > That sounds like the same thing I said, but it uses
> a
> > > lot
> > > > more syllables. Personally I like to make the
> > > requirements
> > > > as simple as possible but alas, as simple as
> possible
> > > > isn't always simple :-(
> > >
> > > I don't know what that has to do with what I am
> saying.
> >
> > You mentioned complex. I've seen plenty of systems
> where
> > complexity is written in that doesn't need to be there.
> > Sometimes system really are complex. Most of the time a
> > simple problem is over architected. I don't know where
> you
> > fall in this continuum. I'll be optimistic and assume
> like
> > you like simple when possible.
>
> You didn't get the point then. The work I do is to
> automate complicated processes. Usually they are vastly
> more complex than they may seem from a distance.
> Multiplying a number by 2 faster is not important in this
> s context. It's kind of banal.
>
> > >
> > > > I don't doubt that, but to call bit-twiddling in
> and
> > of
> > > > itself menial is a gross generalization. Many great
> > > pieces
> > > > of software require bit twiddling and wouldn't be
> > able
> > > to
> > > > meet requirements in any other way.
> > >
> > > That's clearly your assumption, yes.
> > >
> >
> > It's an assumption based on personal experience. You
> can
> > doubt it if you want. You are entitled to your opinion,
> > flawed though it may be.
>
> Sorry, I forgot that you hold all the knowledge of the
> universe and know of every possible approach to a given
> problem.
>

I'm glad you finally realize that.

> I know it's hard to believe that your skills could become
> obsolete but I see it all the time. The COBOL and RPG
> developers I work with are always sure there is no better
> way.
>
> > > > > 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.
> > > >
> > > > I don't see how that signifies something is
> missing.
> > > Maybe
> > > > lower level of abstraction was the wrong phrase. In
> > > some
> > > > instances you have to reduce the number of
> > instructions
> > > > executed or do something clever to get the same
> > result
> > > in
> > > > a more efficient manner. Bit shifting to divide by
> 2
> > > and
> > > > Duff's Device are probably the two most well known
> > > > instances of this. I don't understand how a higher
> > > level
> > > > of abstraction will get you the required
> performance
> > > > improvements in cases like that.
> > >
> > > Why do you think these optimizations have to be made
> a
> > > human?
> > >
> >
> > If the compiler or runtime environment has limitations,
> > who else is going to do them?
>
> I never mentioned a runtime or an environment. What about
> a compiler?
>

Most of the high level languages people speak of have a runtime, like python, C#, java, small talk, etc. I do believe I said "compiler or runtime".

> > I don't doubt that in most
> > cases the runtime or compiler does a great job, but
> > sometimes there are limitations. Compilers and runtimes
> > need to be written to the general case. In many
> instances
> > a much more optimal solution can be written to solve
> your
> > particular problem. That would be the difference
> between
> > theorizing about how to solve a problem and actually
> > solving it.
>
> Whatever. Developers said the same thing when the first
> high-level languages came out.
>

Amazingly, it's still true!

> > You are missing the point. C++ sucks compared to a lot
> > of
> > > languages for the higher abstractions. It's ugly,
> > > inelegant and overcomplicated. To use it in team
> > > development without major maintenance issues you need
> > to
> > > restrict the syntax to a small subset of what is
> > > available. That in itself is costly and inefficient.
> > >
> >
> > That is your opinion. I disagree. I've seen plenty of
> C++
> > that would be mistaken for your beloved java.
>
> We aren't talking about Java and I don't know how many
> times I have to say that I think it's got a lot of
> problems. In any event, if that's the case, the
> developers restricted 'the syntax to a small subset of
> what is available' so it seems like a poor way to argue
> that I am wrong.
>

Ok. Abstractions leak all the time. Because of that I have specific needs from time to time to get closer to the metal than these abstractions allow. Taking that ability away from me impairs my ability to solve problems.

> > > > Python is the language I use at home for a
> > > > lot of things and I've never dropped down to do C
> bit
> > > > twiddling. In the couple of cases I've had to I've
> > just
> > > > done the whole program in C++ (none of the projects
> > > were
> > > > very big) because I had access to both types of
> > > > programming and did not have to switch development
> > > > environments, runtimes or modes of thought.
> > >
> > > Why not take what you needed at the low level and
> make
> > it
> > > reusable for yourself and others in Python?
> > >
> >
> > I can reuse the C++ if I want or need to. From python
> if
> > I'm so inclined. I work better coding the whole initial
> > solution in one place. That's just how I work.
>
> Seems like a limitation to me.
>

Ok.

> > > > > 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.
> > > > >
> > > >
> > > > I don't see this as being a problem with the
> > language.
> > > I
> > > > see this as a problem with the person using the
> > > language.
> > > > I would rather have the freedom to do what I want
> > than
> > > to
> > > > have the language restrict me, much in the same way
> I
> > > > would rather let somebody say something that I find
> > > > offensive than to have my own speech restricted.
> > >
> > > I used to think like that. Then I found out there is
> a
> > > lot more freedom in not having to think about all
> that
> > and
> > > just getting stuff done.
> > >
> >
> > I've had to clean up great swaths of code generated by
> > people with that mindset. Good to know job security
> won't
> > be a problem for me.
>
> And I've fixed uncountable numbers of bugs written be
> people with your mindset.
>

Cool.

> > > > Basically you just said that programming languages
> > are
> > > > becoming lisp, which was invented as a notation for
> > > > describing computations, not as a programming
> > language
> > > per
> > > > se, which is probably why it has survived in a
> > > relatively
> > > > unaltered state for about half a century. Sounds
> very
> > > Paul
> > > > Graham to me.
> > >
> > > Lisp is a very narrow approach to the problem. I
> also
> > > think it's a kind-of a cop out. It seems kind of
> like
> > it
> > > was designed to be easy for the person writing the
> > parser,
> > > not the person using it.
> > >
> >
> > You can read about why LISP was designed the way it was
> > instead of guessing. You said "Programming languages
> are
> > becoming really powerful syntaxes for expressing
> processes
> > and not just mnemonics for micromanaging the hardware."
> > That's a pretty fair summary of what McCarthy says here
>
> And from that you make the leap that I'm talking about
> LISP. That's pretty illogical.
>

How so? I'll assume with your quick response you didn't get through the entire paper. Lisp was create specifically as a notation to express functions, which is how we express processes for a computer. Seems completely logical to me.

> > > > > I think C++ has it's place. It's just not as the
> > > > primary
> > > > > development tool for most software. It's vastly
> > > > overused.
> > > >
> > > > I would say that it is vastly misused if what you
> > > describe
> > > > as the current state of the use of C++ is true. I
> > don't
> > > > think most people grossly misuse the language in
> the
> > > way
> > > > you imagine.
> > >
> > > Really? You think that all the C++ jobs out there
> are
> > for
> > > working on projects that require writing system level
> > > code? I'd say it's probably a lot of teams that
> > need
> > > people to help keep their homemade GUI from falling
> > down
> > > or similar things.
> > >
> >
> > I can quote somebody I know to answer this one "That's
> > clearly your assumption, yes."
>
> I never stated it as if it were a fact, did I?
>

Nope, but you seem full of plenty of opinions about what is wrong with C++ and how you think people "probably use it" that one might wonder what your opinions are based on.

> > > So why use a language that is so punishing if you
> don't
> > > need the low-level stuff. Personally I don't think
> > much
> > > of templates in C++ either. It's the most effective
> > > obfuscation tool I've ever seen. It's the kind of
> > thing
> > > that bugs me about C++. Instead of coming up with
> > clean
> > > designs, developers use a bunch of fancy tricks.
> >
> > A lot of us don't find C++ punishing. Really.
> Intricate,
> > complex, sometimes difficult, yes. But not punishing.
>
> Yes a wonderful tool. Intricate, difficult and complex,
> who could ask for more in a tool. But that's what you
> like about it, right? It's a macho thing.

It allows me to solve certain problems that are either very hard or impossible to solve with other tools. If that's macho, then yeah, it's a macho thing.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: "No sliver bullet" is in the fine print

Posted: Dec 6, 2006 10:09 PM

> I know it's hard to believe that your skills could become
> obsolete but I see it all the time. The COBOL and RPG
> developers I work with are always sure there is no better
> way.

If COBOL and RPG developers are still out there gainfully employed, isn't that rather proof that their skills are not, in fact, obsolete?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: "No sliver bullet" is in the fine print

Posted: Dec 7, 2006 6:18 AM

> Most of the high level languages people speak of have a
> runtime, like python, C#, java, small talk, etc. I do
> believe I said "compiler or runtime".

Sorry missed that. The point is that if a useful feature is missing then it's missing. That doesn't mean it can't be done.

> Ok. Abstractions leak all the time. Because of that I have
> specific needs from time to time to get closer to the
> metal than these abstractions allow. Taking that ability
> away from me impairs my ability to solve problems.

Perhaps. Perhaps you just haven't realized there is a much better approach. A lot of the times that I've seen people drop down to the metal to solve issues, there was a better (faster, less memory, more flexible) solution achieved by adding an abstraction.

> How so? I'll assume with your quick response you didn't
> get through the entire paper. Lisp was create specifically
> as a notation to express functions, which is how we
> express processes for a computer. Seems completely logical
> to me.

I'm fairly familiar with the idea of LISP. Just because I think the idea was good doesn't mean I like that particular execution of it. You're not arguing that this idea leads only LISP, are you?

> Nope, but you seem full of plenty of opinions about what
> is wrong with C++ and how you think people "probably use
> it" that one might wonder what your opinions are based
> on.

My personal experience and conversations like this one.

> It allows me to solve certain problems that are either
> very hard or impossible to solve with other tools. If
> that's macho, then yeah, it's a macho thing.

Give me an an example of the kind of thing you are talking about that you do on a regular basis. Maybe you'll convince me.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: "No sliver bullet" is in the fine print

Posted: Dec 7, 2006 6:28 AM

> > I know it's hard to believe that your skills could
> become
> > obsolete but I see it all the time. The COBOL and RPG
> > developers I work with are always sure there is no
> better
> > way.
>
> If COBOL and RPG developers are still out there gainfully
> employed, isn't that rather proof that their skills are
> not, in fact, obsolete?

I once was on site at an office in 2004 (?) that had a 386 by the copier so they could run one application every week on it. By your logic, this computer is not obsolete. I guess it depends on which definition of obsolete you want to use. What I have seen is that companies are moving away from COBOL and that Java is replacing it. This is being driven largely by IBM.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: "No sliver bullet" is in the fine print

Posted: Dec 7, 2006 7:17 AM

> I once was on site at an office in 2004 (?) that had a 386
> by the copier so they could run one application every week
> on it. By your logic, this computer is not obsolete.

Nice try, James.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: "No sliver bullet" is in the fine print

Posted: Dec 7, 2006 8:00 AM

> > I once was on site at an office in 2004 (?) that had a
> 386
> > by the copier so they could run one application every
> week
> > on it. By your logic, this computer is not obsolete.
>
> Nice try, James.

Huh?


obsolete:
b : of a kind or style no longer current : OLD-FASHIONED <an obsolete technology>

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: "No sliver bullet" is in the fine print

Posted: Dec 7, 2006 10:49 AM

> > Most of the high level languages people speak of have a
> > runtime, like python, C#, java, small talk, etc. I do
> > believe I said "compiler or runtime".
>
> Sorry missed that. The point is that if a useful feature
> is missing then it's missing. That doesn't mean it can't
> be done.
>

It's very hard, if not impossible to do in the general case for a general purpose language. Any useful features need to be (or maybe more correctly should be) applicable to a wide range of problems.

> > Ok. Abstractions leak all the time. Because of that I
> have
> > specific needs from time to time to get closer to the
> > metal than these abstractions allow. Taking that
> ability
> > away from me impairs my ability to solve problems.
>
> Perhaps. Perhaps you just haven't realized there is a
> much better approach. A lot of the times that I've seen
> people drop down to the metal to solve issues, there was a
> better (faster, less memory, more flexible) solution
> achieved by adding an abstraction.
>

I don't disagree with that at all. Unfortunately 'A lot' doesn't cover 'All'. You're not a big fan of templates, so you'll probably hate this, but here is an optimization that I like a lot, not only because it also doesn't look any nastier than regular ol' C++. You get brutally efficient optimization that doesn't look any different than the normal language syntax and this is better than you can do in a lower level language like C to boot. So maybe this supports your argument more than mine? http://www.cantrip.org/emptyopt.html

> > How so? I'll assume with your quick response you didn't
> > get through the entire paper. Lisp was create
> specifically
> > as a notation to express functions, which is how we
> > express processes for a computer. Seems completely
> logical
> > to me.
>
> I'm fairly familiar with the idea of LISP. Just because I
> think the idea was good doesn't mean I like that
> particular execution of it. You're not arguing that this
> idea leads only LISP, are you?
>

I'm not arguing that anything leads invariably to LISP. At least, not its syntax, which what I'll assume you mean by "that particular execution". But the ideas aren't new and the languages that I hear people talk about (python and ruby, mostly) that are going down the path you describe credit at least some of their design to LISP. Invariably overstates the case, but there sure is a high correlation.

>
> > Nope, but you seem full of plenty of opinions about
> what
> > is wrong with C++ and how you think people "probably
> use
> > it" that one might wonder what your opinions are based
> > on.
>
> My personal experience and conversations like this one.
>

Fair enough.

> > It allows me to solve certain problems that are either
> > very hard or impossible to solve with other tools. If
> > that's macho, then yeah, it's a macho thing.
>
> Give me an an example of the kind of thing you are talking
> about that you do on a regular basis. Maybe you'll
> convince me.

I used to help work on a database application that was responsible at times for rolling up 10's to 100's of gigabytes of financial data from leaf level data entry nodes to summary levels for executives. Given the constant changes to financial rules across the globe (the software is sold worldwide), there are constant tweaks to the rollup process. Given the large amounts of data that are processed we need all the control we can get when running this process. The object models and runtimes of more modern languages bring this process to a grinding halt. In order to handle this amount of data there are "tricks" all over the place to conserve memory and shave CPU cycles. For small consolidations that take seconds or minutes, this isn't a big deal. Some of the tweaks, however, were put in place to cut consolidations down from days to hours or, in the best cases, minutes. Performance is a huge deal for this app because nobody wants to start rolling up their database Friday, leave for the weekend and have maybe a 50/50 shot that it will be done when they come in Monday morning.

It has to run and it has to run in a reasonable amount of time and given the need to properly apply the financial rules (order of calculations matter, relationships of certain members in the database change the calculations depending on financial rules covering partially and wholly owned subsidiaries based on country, etc.) you don't have a lot of wiggle room with the algorithms. You have some but not much because the numbers have to be right. The only practical alternative is to make the computations take less time.

Flat View: This topic has 212 replies on 15 pages [ « | 11 12 13 14 15 | » ]

Previous Topic

Next Topic