4 ms·

You won't see (#a,b#) in client code, that's hidden behind the facade of a library, unless you are very desperate. Nor will you use pointers.

by IsTom 12y ago

Nursie 12y ago
So... this is somebody else's problem and smarter people will take care of it for me? I've never found that answer very satisfying...
- freyrs3 12y ago
  Do you assemble your own machine code as well or do you trust that someone else has taken care of the gritty details of the assembler so that you can work at a level of abstraction higher than that?
  - bronson 12y ago
    Assembling a program into machine language is simple enough that it's easy to trust someone else to get it right. I imagine it depends on the difficulty of the problem being outsourced.
    - SoftwareMaven 12y ago
      Have you seen what optimizing compilers do? I'd hardly call that simple!
      - bronson 12y ago
        Thought it was clear the OP was talking about assembly? Which, thanks to pipeline stalls and out-of-order execution is no walk in the park these days, but it's not TOO bad.
- Dewie 12y ago
  > So... this is somebody else's problem and smarter people will take care of it for me? Smarter is your opinion. Is a library writer smarter than an app developer? Is a compiler writer smarter than a library writer? Perhaps, though I don't see how that is a given. I look at it more like; compilers will be used by more people than a single library, so it pays off to spend more time on developing, testing, debugging, etc. it than a library. A library might be used by more clients than a single app, so it pays off to use more time on it and optimize it, which might include unsafe features. If people that work "further down the stack" are necessarily smarter than those in the upper layers, we programmers must be pretty stupid... :)
  - alextgordon 12y ago
    Bjarne says in his book that he wanted to make C++ implementable with just nothing more complicated than a linear search. Things didn't quite work out that way, but it's a good principle for language designers to live by. If you don't know how to implement the languages you use, then either you or the language is at fault, IMO.
    - Dewie 12y ago
      That's a pretty absolute rule to live by. I think there is merit in the idea - it's nice to be able to easily know what is going on. If I was making a language - and I could do as I wanted - I would make try to make the compilation step fully "debuggable", ie being able to step through the whole compilation, even stop and modify things, mess around, etc. Compilers seem awfully black-boxy, in general. (Forth might be one of the ultimate expressions of the principle of a fully understandable compiler - Chuck Moore even hesitates to call it a compiler.) On the other hand, you can get very far without really losing anything if you just know the semantics of the language, and leave the nitty-gritty to the compiler. C is supposed to be simple, but given how big of a deal optimizing compilers for C seems to be, it's not straightforward to make a proper, industrial standard compiler for the language (perhaps both with regards to competition and effort). And yet C is supposedly just a thinly-veiled abstraction over assembly ("supposedly" since I'm not a C programmer). I for one welcome giant, too-big-to-understand-for-one-person compilers, as long as they are awesome at what they do. Simple programming language? Then you seem to get complicated design patterns. Simple semantics ala "everything is X" (immutable, object, ...)? Then you get complicated work-around in the places where you can't/don't want immutability/objects... . Simple compiler? Lot's of responsibility and mental overhead for each individual programmer, in a sense duplicating a lot of the effort that could be handled by a team of compiler writers, once.
- IsTom 12y ago
  Works for libc.

You won't see (#a,b#) in client code, that's hidden behind the facade of a library, unless you are very desperate. Nor will you use pointers.

by IsTom 12y ago

You won't see (#a,b#) in client code, that's hidden behind the facade of a library, unless you are very desperate. Nor will you use pointers.

Nursie 12y ago

So... this is somebody else's problem and smarter people will take care of it for me? I've never found that answer very satisfying...

freyrs3 12y ago
Do you assemble your own machine code as well or do you trust that someone else has taken care of the gritty details of the assembler so that you can work at a level of abstraction higher than that?
- bronson 12y ago
  Assembling a program into machine language is simple enough that it's easy to trust someone else to get it right. I imagine it depends on the difficulty of the problem being outsourced.
  - SoftwareMaven 12y ago
    Have you seen what optimizing compilers do? I'd hardly call that simple!
    - bronson 12y ago
      Thought it was clear the OP was talking about assembly? Which, thanks to pipeline stalls and out-of-order execution is no walk in the park these days, but it's not TOO bad.
Dewie 12y ago
> So... this is somebody else's problem and smarter people will take care of it for me? Smarter is your opinion. Is a library writer smarter than an app developer? Is a compiler writer smarter than a library writer? Perhaps, though I don't see how that is a given. I look at it more like; compilers will be used by more people than a single library, so it pays off to spend more time on developing, testing, debugging, etc. it than a library. A library might be used by more clients than a single app, so it pays off to use more time on it and optimize it, which might include unsafe features. If people that work "further down the stack" are necessarily smarter than those in the upper layers, we programmers must be pretty stupid... :)
- alextgordon 12y ago
  Bjarne says in his book that he wanted to make C++ implementable with just nothing more complicated than a linear search. Things didn't quite work out that way, but it's a good principle for language designers to live by. If you don't know how to implement the languages you use, then either you or the language is at fault, IMO.
  - Dewie 12y ago
    That's a pretty absolute rule to live by. I think there is merit in the idea - it's nice to be able to easily know what is going on. If I was making a language - and I could do as I wanted - I would make try to make the compilation step fully "debuggable", ie being able to step through the whole compilation, even stop and modify things, mess around, etc. Compilers seem awfully black-boxy, in general. (Forth might be one of the ultimate expressions of the principle of a fully understandable compiler - Chuck Moore even hesitates to call it a compiler.) On the other hand, you can get very far without really losing anything if you just know the semantics of the language, and leave the nitty-gritty to the compiler. C is supposed to be simple, but given how big of a deal optimizing compilers for C seems to be, it's not straightforward to make a proper, industrial standard compiler for the language (perhaps both with regards to competition and effort). And yet C is supposedly just a thinly-veiled abstraction over assembly ("supposedly" since I'm not a C programmer). I for one welcome giant, too-big-to-understand-for-one-person compilers, as long as they are awesome at what they do. Simple programming language? Then you seem to get complicated design patterns. Simple semantics ala "everything is X" (immutable, object, ...)? Then you get complicated work-around in the places where you can't/don't want immutability/objects... . Simple compiler? Lot's of responsibility and mental overhead for each individual programmer, in a sense duplicating a lot of the effort that could be handled by a team of compiler writers, once.
IsTom 12y ago
Works for libc.