C++ in Coders at Work • Hacker News Board

Re: C++ in Coders at Work

#141

Post by jacquesm » Sat, Oct 17, 2009, 12:59 AM UTC

LogicHoleFlaw wrote: post #129

russell wrote: post #122

Earlier quoted context omitted.

In general, hardware optimized for high-level languages have been a failure, usually the extra baggage for handling things as machine-level interpreter slow things down nearly as much as a software interpreter. Nothing has been a real commercial success and it isnt for want of trying. Off the top of my head I can think of the Burroughs B5500 which had hardware support for typed data, the Lisp Machine, and the Intel 4…

IBM has plug-in hardware JVMs for its mainframe big iron. They are ungodly expensive.

I can't find anything about that, it's quite interesting do you have a link ?

edit: found it:

http://news.zdnet.com/2100-9584_22-135319.html

Re: C++ in Coders at Work

#142

Post by Tuna-Fish » Sat, Oct 17, 2009, 1:02 AM UTC

joe_the_user wrote: post #90

jimbokun wrote: post #76

Earlier quoted context omitted.

"Part of how C++ is successful is that it retains C compatibility" I think Objective C is a better object oriented C than C++. It's simpler, makes a syntactic distinction between message passing and "traditional" C, and has a more dynamic run time. I'm surprised no one else has brought up Objective C as a better solution to the "make C object oriented" problem.

Recently, I went from Ruby on Rails web programming to C++ w/Qt GUI programming. Using the C++ features that I choose, C++ is actually pretty fast to develop on... (I did MFC years ago and that was nasty but Rails internal code is also awful, with fifty-million separate classes just for exceptions). Aside from C compatibility, C++ also allows one to create simple structures and procedures when such simple beasts are…

I just have to nitpick here: Strong typing is always a good feature, and weak typing is always a bad one.

Now, whether the types should be dynamic or static, is entirely up to the situation and what kind of system you are building.

Re: C++ in Coders at Work

#143

Post by aboodman » Sat, Oct 17, 2009, 1:08 AM UTC

jacquesm wrote: post #11

aboodman wrote: post #3

Argh. Not a very useful article. Start with an observation: "Everyone hates C++, and yet it is really widely used. That's odd." Next, 10 paragraphs of people hating on C++. End with: actually wait, no ending.

Well, the 'everyone' he is talking about are some of the most respected people in the computer world, that should count for something. Also, they make fairly specific criticisms, and they have a track record of being right about such things. Java seems to be the C++ replacement of the future, with C# pulling the other way.

The point I was trying to make wasn't about C++, it was that the article starts with a question it never answers.

It would be a more honest opening to just say "lots of smart people hate C++", and then proceeded with the examples.

Instead, it pretends like it is going to answer the question of why it is so popular in spite of being widely reviled, but then never touches on that.

edit: grammar

Re: C++ in Coders at Work

#144

Post by Tuna-Fish » Sat, Oct 17, 2009, 1:17 AM UTC

russell wrote: post #122

loup-vaillant wrote: post #25

Earlier quoted context omitted.

I totally agree. C++ main strength lies in its "portable assembler" nature. However, C++ also is [quite a behemoth][1], while Lisp, Python and Haskell aren't so. [1]: http://yosefk.com/c++fqa/ The answer then is obvious : we should change the hardware, so it is not C/C++ optimized, but Lisp/Python/Haskell optimized. Then, these languages are easier and more practical.

In general, hardware optimized for high-level languages have been a failure, usually the extra baggage for handling things as machine-level interpreter slow things down nearly as much as a software interpreter. Nothing has been a real commercial success and it isnt for want of trying. Off the top of my head I can think of the Burroughs B5500 which had hardware support for typed data, the Lisp Machine, and the Intel 4…

There's Jazelle for ARM, it's essentially a instruction overlay that makes the cpu execute all simple and common java bytecodes directly, and call a kernel function for all the hard ones.

However, even that is dying -- it is being replaced by the thumbEE, which is a more generic instruction set designed for efficient code generation from intermediate dynamic code.

Re: C++ in Coders at Work

#145

Post by hmmmm » Sat, Oct 17, 2009, 1:53 AM UTC

jacquesm wrote: post #68

dkarl wrote: post #52

Earlier quoted context omitted.

It was more the other way around, I think. Implementers had a lot of power to say, "No, this can't be done efficiently," and as a result, the burden was passed to programmers instead. Can you give an example of a "pet construct" (aside from major features like multiple inheritance and exception handling) that could have been left out?

I think operator overloading, which seemed like a 'great idea at the time' with some forethought should have never been part of the language in the way it works right now. The times that I ran in to examples where it was used properly and elegantly I think it could have been done just as nice with a properly named function call. I think the way it workd came from the DSL camp arguing that you should be able to make i…

>done just as nice with a properly named function call.

So instead of view = projection * model; you would prefer.

view.SetVector(Multiply3x3matrixWith3x1Vector(projection.GetMatrix(),model.GetVector());

Should we allow floats an doubles to be multiplied with a'*' or should that use properly named classes

Re: C++ in Coders at Work

#146

Post by scott_s » Sat, Oct 17, 2009, 2:38 AM UTC

jacquesm wrote: post #136

scott_s wrote: post #125

Earlier quoted context omitted.

Most users also probably have their own favorite subset of Word.

You've nailed it right on the head there though, when offered a bloated solution, people will 'subset', when offered something small and powerful people will customize.

You missed my point. Most users each probably have a different subset of Word.

Re: C++ in Coders at Work

#147

Post by known » Sat, Oct 17, 2009, 3:02 AM UTC

Isn't C++ Compiler written in C?

Re: C++ in Coders at Work

#148

Post by jacquesm » Sat, Oct 17, 2009, 3:04 AM UTC

scott_s wrote: post #146

jacquesm wrote: post #136

Earlier quoted context omitted.

You've nailed it right on the head there though, when offered a bloated solution, people will 'subset', when offered something small and powerful people will customize.

You missed my point. Most users each probably have a different subset of Word.

No, I got it all right, that's what I meant. Each user subsets word for themselves in to what they need/can handle.

Re: C++ in Coders at Work

#149

Post by barrkel » Sat, Oct 17, 2009, 3:27 AM UTC

barrkel wrote: post #131

jacquesm wrote: post #115

Earlier quoted context omitted.

I think you're missing the point here. A C program that accesses the memory will do so in an extremely predictable way, if I lay out a memory structure, a piece of code and an access pattern then I can be very sure about how that will interact with things like the caches. In other languages where there is more 'under the hood' that is a lot harder. Libraries don't enter in to the problem, that's another level altoget…

I think my point is that you can lose track of the woods for all the trees; moreover, C is not actually a good map with the underlying hardware. In C, you deal with so many trees, it sure feels like you're right there in the woods. But actually, if you're dealing with things on a tree by tree basis, you're not getting much done. And you can pretty lose your way by focusing on navigating territory efficiently at that…

Don't you just love drive-by readers who downvote all your comments in a thread, and never leave a reply indicating why they disagree with you? Because I sure do...

Re: C++ in Coders at Work

#150

Post by barrkel » Sat, Oct 17, 2009, 3:40 AM UTC

jacquesm wrote: post #140

barrkel wrote: post #111

Earlier quoted context omitted.

The computer is actually has a von Neumann architecture, that is, they have code and data in the same address space. To the degree that C represents this reality, it is through exploits: e.g. buffer overflows, overwriting the stack and return address, and executing arbitrary code supplied by attackers. C itself does not represent the reality very well, since it does not lend itself to writing code that writes code at…

> The computer is actually has a von Neumann architecture, that is, they have code and data in the same address space. The ones that do not are actually pretty rare. Most of those use the 'harvard architecture' and are DSP style machines. And then there are vector processors and SIMDs, but even those can be seen as many von Neumann machines running in lock-step.

The (vast) majority of programmers are not programming DSP-style machines, so like I said, and I still stand by it, C doesn't map well to the full functionality of the von Neumann architecture.