Google executive frustrated by Java, C++ complexity

This is a discussion on Google executive frustrated by Java, C++ complexity within the General Discussions forums, part of the Community Boards category; Yeah. Basically there is no real reason to get uppity and none of this matters. Let's not let them wind ...

  1. #16
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,524
    Yeah. Basically there is no real reason to get uppity and none of this matters. Let's not let them wind us up, like C++ needs defending. This is the free world and people are allowed to express their opinions no matter their validity. Go is just Google's answer to people who'd respond with: "Oh yeah? Then do something better." Google likes to just jump in and do things, anyway.

  2. #17
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,167
    /me wonders if it will turn out like VP8.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.
    For information on how to enable C++11 on your compiler, look here.
    よく聞くがいい!私は天才だからね! ^_^

  3. #18
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,524
    Are you sure comparisons between file formats and languages are valid?

  4. #19
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,167
    With regard to some things, yes. Specs, encoders/decoders (compilers in this case) should be the same.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.
    For information on how to enable C++11 on your compiler, look here.
    よく聞くがいい!私は天才だからね! ^_^

  5. #20
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,383
    The point however is not about Go. It's about C++. I don't think many people outside Google care for what Go will become.

    And far less who believe it will amount to anything meaningful. There's so much you can do trying to abstract today's challenges. We need to invent new paradigms. Not new syntaxes.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  6. #21
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Just because C++ is horribly verbose doesn't mean it's "complex". Gosh, that's the only reason I'd be happy to ditch it. Perl anyone ?

    The point however is not about Go. It's about C++. I don't think many people outside Google care for what Go will become.
    It's gaining enormous momentum in the academic arena. Much like Eiffel did.

    Quote Originally Posted by Elysia View Post
    It will take an even longer time to create a new language.
    And is Google really promoting this language? If it is, then it will face these problems sooner or later.
    And really? Garbage collected? Systems programming? That's just asking to fail.
    ... How is being Garbage collected or aimed at systems programming asking to fail? You like to do a lot of stirring when you obviously have no clue.

  7. #22
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,584
    Let's not let them wind us up, like C++ needs defending.
    My sentiments exactly. It has more than proven itself through the years. For those who do not think it is relevant any more or somehow automatically costs more development time even when there are about a billion lines of open source solutions for pretty much anything you need to do there is nothing I can do or say to change their mind. Why waste my time trying to do so?

  8. #23
    Disrupting the universe Mad_guy's Avatar
    Join Date
    Jun 2005
    Posts
    258
    Quote Originally Posted by Elysia
    I don't see how it could be different. Perhaps you have an idea? I would be very interested in hearing it.
    Basically just get rid of the C preprocessor in favor of a real module system - you can still reap the benefits of having the specification (i.e. header) separate from the implementation (i.e. module,) but basically not have to deal with all the dumbness of only being able to do essentially textual includes for source code. You actually gain a lot because you can enforce module-level invariants, like certain things are exposed and others are not, and basically all module systems give you the ability to qualify names, so you do not have to namespace everything in order to make sure you aren't going to conflict with things. With hierarchical module structure, you pretty much get all the benefits of namespaces but without the crappiness of CPP. I've mentioned this elsewhere, but the C-preprocessor is the reason the C++ standard library headers look like such complete and total crap, because if you they weren't you could do "#define StrBuf lolitron;" before including iostream - then boom, textual substitution at the preprocessing level causes everything to explode. Hence underscoring things to hell and making them illegible and unreadable. And keep in mind the C++ standard specifies you must do this in order to avoid naming conflicts - Microsoft apparently write their C++ headers using an actually readable style, before running them through a name/identifier obfuscator on their side, the resulting files which they ship to developers for the Windows SDK (so you basically can't possibly clash names.)

    Quote Originally Posted by Elysia
    Do you have examples? I'd love to see such things.
    Simple example: a vector type which is parametrized by its current length (i.e. the type is something abstractly like 'vector 5 int' meaning "this value is a vector of length 5 containing only ints".) You can then parametrize functions over these vectors and enforce invariants in your code. Example: addition of two vectors of length n and m is basically undefined behavior if n != m, or better put, addition is only defined precisely over two vectors of lengths n and m where n == m. You can express this invariant using the type system when defining a function like addition by saying it can only take two vectors where their types say they have the same length. The result is that if you add a vector of length 4 with a vector of length 5, you actually get a compile-time error because the invariant is enforced through the type system.

    I think this can be done in C++ and if anybody would like to take a stab at it, I'd like to see the code, even if the result is only a trivially usable vector type! (and I'll respond with my own code doing the same thing, only in a much more high level language to show a contrast in type system expressiveness.) The result almost always results in the usage of Peano numbers at the type level, so if anybody would like to take a stab at it that's a good starting point.

    Quote Originally Posted by SMurf
    Example: Because I have written quite a few (amateur) Win32 applications over the years, I can create new applications using my head as a reference instead of MSDN. You can hypothesize from this that over a number of 7.5 hour days, where the objective is to develop a Win32 application, that I am likely to be more productive than someone who hasn't played about with things custom window messages, synchronization objects, etc.
    Um, okay, but none of this addresses the fact you were still drawing some weird false dichotomy in your original post between "seasoned developers" and "inexperienced developers" supporting it with the notion that inexperienced developers will "stick their heads in so-and-so API reference." Why would a 'seasoned developer' not need an API reference from time to time? These things are completely orthogonal, and a totally horrible metric is what I'm saying. It's good that you are familiar with the Win32 API, but I don't think that's really any indicator of you being "seasoned" or something because you won't need an API reference or whatever in the case you need to write a Win32 app.

    Quote Originally Posted by SMurf
    Exactly. The people who could make this complexity go away are too scarce. Changing the programming language is the long-winded solution compared with improving education and professional standards. I made my initial comparison with surgery/medicine for a reason.
    Um, this is Google we are talking about, not run-of-the-mill crap developers who don't know what they're doing. I think the people they have working for them are of plenty high quality, so I wouldn't be so quick to say they need to improve their "standards."

    Quote Originally Posted by SMurf
    Oh I see... he's really really v. important, so I must automatically agree with everything he says?
    When did I say you should just agree with him? You're just being ridiculous now because you can't answer the actual point I'm making, because I never said you should just "agree" with him, I only highlighted his motivation behind such decisions because I think it's sound: Pike is noting problems and pain points he and other people have with existing programming languages at Google, and how he and his team at Google are attempting to fix them through Go. There is nothing wrong with this as a thesis. Why do I think this is sound, as opposed to him just 'making it up'? Because he isn't the first person to realize pitfalls in existing languages and certainly won't be the last. You on the other seem to only believe he's making noise for no reason, or a solution to a non existent problem, which I don't quite buy (although like I said earlier, whether or not it's a solution to problems outside of Google has yet to be fully seen, although it seems to have adopted a reasonably healthy community.)

    His implementation of his thesis, Go, may be, um, "underwhelming" in some ways, but it is not without some merit or goal.

    Quote Originally Posted by SMurf
    Do you not think that perhaps he is pushing his company's idea for wider acceptance? Obviously such an exalted engineer ought to be immune to scrutiny.
    Um, no. I have plenty of complaints about Go as a programming language. It has nothing to do with him being 'immune to scrutiny', and everything to do with him highlighting pain points with existing languages and outlining his solution to them. It appears that he is not the only person inside Google who shares his sentiments, either, and hence, Go was born as a solution to their problems.

    Quote Originally Posted by zacs7
    Just because C++ is horribly verbose doesn't mean it's "complex".
    Realistically, from a semantic perspective and a tool perspective, C++ is an incredibly complex language the likes of which are not rivaled easily - as I said before, simply parsing C++ is not only non-context free (and neither is C for that matter,) it actually requires semantic analysis in order to parse correctly (making the two impossible to separate,) and its grammar is actually undecidable because the template language makes the type system turing complete, meaning programs can actually fail to compile because the compiler would otherwise 'not halt' (although you can change the recursion threshold at the template level for pretty much any compiler, but this still does not guarantee it will 'halt'.) The result is pretty much no extremely robust tools which can handle C++ in its entirety for the purposes of refactoring or simply parsing.
    Last edited by Mad_guy; 07-24-2010 at 07:56 PM.
    operating systems: mac os 10.6, debian 5.0, windows 7
    editor: back to emacs because it's more awesomer!!
    version control: git

    website: http://0xff.ath.cx/~as/

  9. #24
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,383
    Quote Originally Posted by Bubba View Post
    My sentiments exactly. It has more than proven itself through the years. For those who do not think it is relevant any more or somehow automatically costs more development time even when there are about a billion lines of open source solutions for pretty much anything you need to do there is nothing I can do or say to change their mind.
    It's not about having become irrelevant or costing more development time. It's about having lost to other languages in certain areas of development exactly because it's more complex and time consuming than those languages. C++ is -- and will remain -- essential. But there's no denying it lost space to other programming languages that surfaced in the meantime.

    Quote Originally Posted by MadGuy
    I've mentioned this elsewhere, but the C-preprocessor is the reason the C++ standard library headers look like such complete and total crap
    And I've told you before on another thread, but you didn't listen; It's none of your business how the standard library headers look like. They are properly documented. You have no place trying to interpret them.

    Quote Originally Posted by MadGuy
    Basically just get rid of the C preprocessor in favor of a real module system - you can still reap the benefits of having the specification (i.e. header) separate from the implementation (i.e. module,) but basically not have to deal with all the dumbness of only being able to do essentially textual includes for source code. You actually gain a lot because you can enforce module-level invariants, like certain things are exposed and others are not, and basically all module systems give you the ability to qualify names, so you do not have to namespace everything in order to make sure you aren't going to conflict with things.
    To tell you frankly I find it increasingly annoying when i see C++ criticism the comes with proposed solutions that are perfectly capable of being dealt with by C++. We all heard it before; "C++ doesn't do this. C++ doesn't have that". And all the time the answer is either you can do it yourself using C++, or already someone did it for you and here's the library.

    The matter of the fact is that there is absolutely nothing stopping you from implementing this in C++. And that's precisely this programming language biggest strength. "There's nothing you can't do". Not many can claim the same.

    - For one, you can simply use the linker: Want modules? Create your own DLLs and link in your project.
    - Not good enough? Want runtime access? Use the compiler: Use dlopen() in unix or loadlibrary() in windows.
    - Not good enough? Write your own interpreter.

    3 different layered solutions to your problem. However you look at it, the programming language offers you the tools to do it.

    So why on earth would anyone (including the C++ standards committee) want to make your modules-thingy the new standard way of accessing libraries contents? Explain that to me in the context of a general-purpose language like C++.
    Last edited by Mario F.; 07-24-2010 at 08:54 PM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  10. #25
    Disrupting the universe Mad_guy's Avatar
    Join Date
    Jun 2005
    Posts
    258
    And I've told you before on another thread, but you didn't listen; It's none of your business how the standard library headers look like. They are properly documented. You have no place trying to interpret them.
    What on EARTH is that supposed to mean, "I have no place trying to interpret them"? This is maybe the biggest load of crap I have ever heard. Maybe I, you know, would like to read them? Maybe I would like to contribute to something to the standard libraries (something like GNU's C++ stdlib, or the LLVM projects libc++) or enhance them? What if I wanted to write my own implementation of the STL because none of the other ones fit my need (which isn't unrealistic, btw)? How dare you say I have no place in attempting to interpret these things, presumably because you believe I only mention this out of spite and not out of perhaps the need and want to actually do something with them? (because in some cases, I do.) This is an outrageously offensive thing to say quite frankly, and I'd appreciate it if you could not be an ivory-tower "you have no place being here" dickhead on the matter, because that's not an excuse for the C++ standard library header files looking like complete ass and hence making them unreadable and essentially illegible. Sorry.

    To tell you frankly I find it increasingly annoying when i see C++ criticism the comes with proposed solutions that are perfectly capable of being dealt with by C++. We all heard it before; "C++ doesn't do this. C++ doesn't have that". And all the time the answer is either you can do it yourself using C++, or already someone did it for you and here's the library.
    I didn't propose this as some sort of solution which should be implemented in C++ - I highlighted why I think the C preprocessor sucks, why it necessitates the need for something like 'namespace' to avoid naming conflicts all over the place and as a result makes many identifiers verbose, and why a proper module system (found in many programming languages) would alleviate many of these problems and still give your language just as much expressive power in the end.

    If I gave you the implication I wanted this in C++, I don't. It would never happen anyway. I was asked how I thought these things could be alleviated by Elysia, and I answered appropriately with what I think would solve it: a real module system. As opposed to crappy textual includes a la CPP (and luckily I think no other language in existence has really made the mistake of adopting CPP in this manner because it's a terrible solution to such a problem these days.)

    The matter of the fact is that there is absolutely nothing stopping you from implementing this in C++. And that's precisely this programming language biggest strength. "There's nothing you can't do". Not many can claim the same.
    I don't give a crap if I can reconstruct anything built by man to date with only a hammer and nails, it's damn obvious to me that I can get the job done easier, faster and better using a more modern tool. And I can. So I do.

    - For one, you can simply use the linker: Want modules? Create your own DLLs and link in your project.
    - Not good enough? Want runtime access? Use the compiler: Use dlopen() in unix or loadlibrary() in windows.
    - Not good enough? Write your own interpreter.
    None of these really have ANYTHING to do with what I was talking about. At all. Shared libraries and the like are totally orthogonal to having a real module system in your programming language. Go look into it.

    3 different layered solutions to your problem. However you look at it, the programming language offers you the tools to do it.
    Oh believe me, I'm sure it does have tools to do these things, even if those tools totally suck in almost every way. I'd rather just use something which sucks less.

    So why on earth would anyone (including the C++ standards committee) want to make your modules-thingy the new standard way of accessing libraries contents? Explain that to me in the context of a general-purpose language like C++.
    What the hell? "Explain to me why you would want a module system in a general-purpose programming language"? Did you even READ anything I said on the matter, understand it, or even know what I'm talking about when I say a 'real module system', as opposed to 'totally crappy textual include systems a la CPP'? Maybe you should go use a programming language that, uh, isn't C++ or something. Go try Standard ML or something, it has an incredibly awesome module system, for example, and you'd probably better understand what I was talking about after the fact, because you clearly don't as evidenced by your rant about linkers/dlopen as a "solution" and now wonder why anybody would "want a module system" in a "general purpose language."
    Last edited by Mad_guy; 07-24-2010 at 11:53 PM.
    operating systems: mac os 10.6, debian 5.0, windows 7
    editor: back to emacs because it's more awesomer!!
    version control: git

    website: http://0xff.ath.cx/~as/

  11. #26
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    20,968
    Quote Originally Posted by Mad_guy
    Simple example: a vector type which is parametrized by its current length (i.e. the type is something abstractly like 'vector 5 int' meaning "this value is a vector of length 5 containing only ints".) You can then parametrize functions over these vectors and enforce invariants in your code. Example: addition of two vectors of length n and m is basically undefined behavior if n != m, or better put, addition is only defined precisely over two vectors of lengths n and m where n == m. You can express this invariant using the type system when defining a function like addition by saying it can only take two vectors where their types say they have the same length. The result is that if you add a vector of length 4 with a vector of length 5, you actually get a compile-time error because the invariant is enforced through the type system.

    I think this can be done in C++ and if anybody would like to take a stab at it, I'd like to see the code, even if the result is only a trivially usable vector type! (and I'll respond with my own code doing the same thing, only in a much more high level language to show a contrast in type system expressiveness.) The result almost always results in the usage of Peano numbers at the type level, so if anybody would like to take a stab at it that's a good starting point.
    It sounds like you are talking about something along the lines of the design by contract feature of Eiffel. If I am not mistaken, the example here cannot be done in C++ since current length could change at run time, and thus you need to write code to handle the invariant checking at run time instead of just using the C++ template functionality to enforce it at compile time, i.e., the type cannot include the length. On the other hand, if this vector type is limited such that the length is always determined at compile time, then it becomes very similiar to std::tr1::array (other than having a different interface, of course).
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  12. #27
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,167
    Quote Originally Posted by zacs7 View Post
    ... How is being Garbage collected or aimed at systems programming asking to fail? You like to do a lot of stirring when you obviously have no clue.
    I fail to see how it could work. Those embedded systems with a few KB of ram? Which the garbage collector would sit eating all the time?
    And then the problem of deterministic construction. Not saying such a thing isn't possible with GC, but it sure would made it a whole lot harder.
    Locking pointers... Barking instructions at the GC...
    I don't see how it's beneficial for embedded systems.

    Quote Originally Posted by Mad_guy View Post
    Basically just get rid of the C preprocessor in favor of a real module system - you can still reap the benefits of having the specification (i.e. header) separate from the implementation (i.e. module,) but basically not have to deal with all the dumbness of only being able to do essentially textual includes for source code. You actually gain a lot because you can enforce module-level invariants, like certain things are exposed and others are not, and basically all module systems give you the ability to qualify names, so you do not have to namespace everything in order to make sure you aren't going to conflict with things. With hierarchical module structure, you pretty much get all the benefits of namespaces but without the crappiness of CPP. I've mentioned this elsewhere, but the C-preprocessor is the reason the C++ standard library headers look like such complete and total crap, because if you they weren't you could do "#define StrBuf lolitron;" before including iostream - then boom, textual substitution at the preprocessing level causes everything to explode. Hence underscoring things to hell and making them illegible and unreadable. And keep in mind the C++ standard specifies you must do this in order to avoid naming conflicts - Microsoft apparently write their C++ headers using an actually readable style, before running them through a name/identifier obfuscator on their side, the resulting files which they ship to developers for the Windows SDK (so you basically can't possibly clash names.)
    That's interesting. But if you follow the convention that all macros should be UPPER CASE, then there should be no problem, though?
    I suspect it's because they want thing not to break if someone breaks it?

    Simple example: a vector type which is parametrized by its current length (i.e. the type is something abstractly like 'vector 5 int' meaning "this value is a vector of length 5 containing only ints".) You can then parametrize functions over these vectors and enforce invariants in your code. Example: addition of two vectors of length n and m is basically undefined behavior if n != m, or better put, addition is only defined precisely over two vectors of lengths n and m where n == m. You can express this invariant using the type system when defining a function like addition by saying it can only take two vectors where their types say they have the same length. The result is that if you add a vector of length 4 with a vector of length 5, you actually get a compile-time error because the invariant is enforced through the type system.

    I think this can be done in C++ and if anybody would like to take a stab at it, I'd like to see the code, even if the result is only a trivially usable vector type! (and I'll respond with my own code doing the same thing, only in a much more high level language to show a contrast in type system expressiveness.) The result almost always results in the usage of Peano numbers at the type level, so if anybody would like to take a stab at it that's a good starting point.
    Ah, I get what you mean. But what you are trying to do is impossible. A vector is a dynamic containers. That is, its size can change at runtime. So there would be absolutely impossible for us to know the size of it at compile time. But we could use an assert:
    assert(v1.size() == v2.size());
    It's better than nothing.
    Now, there are actually 3 solutions to this problem without using vectors.
    The first is with standard C arrays:

    Code:
    template<typename T, int N1, int N2> void AddVec(T (&Vec1)[N1], T (&Vec2)[N2])
    {
        static_assert(N1 == N2);
    }
    The second is using std::array variant 1:

    Code:
    template<typename T, int N1, int N2> void AddVec(std::array<T, N1>& Vec1, std::array<T, N2>& Vec2)
    {
        static_assert(N1 == N2);
    }
    And the third is using std::array variant 2:
    Code:
    template<typename T> void AddVec(T & Vec1, T & Vec2)
    {
        static_assert(Vec1.size == Vec2.size);
    }
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.
    For information on how to enable C++11 on your compiler, look here.
    よく聞くがいい!私は天才だからね! ^_^

  13. #28
    Registered /usr
    Join Date
    Aug 2001
    Location
    Newport, South Wales, UK
    Posts
    1,255
    Quote Originally Posted by Mad_guy View Post
    Why would a 'seasoned developer' not need an API reference from time to time?
    Because they already know about what they are trying to achieve?!? This is hard work.

    At no point did I say that seasoned developers wouldn't refer to a book. My point is that inexperienced developers will more likely to be reading about a given API while experienced developers will have come across it before and would be coding in the same time.

    "Totally horrible metric" is accurate, because totally horrible management exists. I'm sure you're familiar with the idea that counting how many lines someone has written in a day is a valid measurement of productivity. Complex problems have the effect of stalling the project, according to this metric. And yet people are still working. The management takes the moment to remind the developers of deadlines, they polish something up and it becomes the final product. A major bug is later discovered, management blows a fuse and demands an explanation. The developers say that they were still working on the problem and can fix it, given the time.

    Now, which type of developer is generally better with their time?

    Quote Originally Posted by Mad_guy View Post
    Um, this is Google we are talking about, not run-of-the-mill crap developers who don't know what they're doing. I think the people they have working for them are of plenty high quality, so I wouldn't be so quick to say they need to improve their "standards."
    Yes, but Google are not keeping this to themselves. They want other people to use it. Other people != Google.

    Quote Originally Posted by Mad_guy View Post
    When did I say you should just agree with him?
    You seemed to be implying that I thought he was lying. At no point did I use that word, I only expressed skepticism about the need for the language that he is pushing. Disagreement fits my words better.

    Quote Originally Posted by Mad_guy View Post
    His implementation of his thesis, Go, may be, um, "underwhelming" in some ways, but it is not without some merit or goal.
    See? You can write sensible things now and then.

    I am not asking him to jump off a bridge or anything, I simply feel that his idea is not the revolution some people are spinning it into.

  14. #29
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,383
    Quote Originally Posted by Mad_guy View Post
    What on EARTH is that supposed to mean, "I have no place trying to interpret them"? This is maybe the biggest load of crap I have ever heard. Maybe I, you know, would like to read them? Maybe I would like to contribute to something to the standard libraries (something like GNU's C++ stdlib, or the LLVM projects libc++) or enhance them?
    Given your criticism of the standard library, maybe you shouldn't. There's not many places where I heard such a violent attack at decades of hard work from highly trained contributors to the programming language.

    This is an outrageously offensive thing to say quite frankly, and I'd appreciate it if you could not be an ivory-tower "you have no place being here" dickhead on the matter, because that's not an excuse for the C++ standard library header files looking like complete ass and hence making them unreadable and essentially illegible. Sorry.
    You are excused. While I do understand the goals, I'm sure people when they decide to work on the standard library, are qualified enough to understand namespaces and make heads from tails of the whole library. While I can imagine they may occasionally sigh at one choice or another, I cannot imagine them being so violently anal about it.

    None of these really have ANYTHING to do with what I was talking about. At all. Shared libraries and the like are totally orthogonal to having a real module system in your programming language. Go look into it.
    Maybe you don't understand: You cannot have a module system in C++, unless you implement it because C++ is not meant to give you a module system. Neither it probably ever will. You want a drawing? The three solutions I gave you are a step in that direction in the context of C++.

    You seem to be all for modules. Cool. Use a language that implements modules. You already do? Cool. So now take your feet off my lawn.

    The problem with you folks is that you keep insisting in bringing into the C++ table issues that are by design. SML is not without its detractors. The different between you and me is that I'm not going to call SML a pile of rubbish because it doesn't implement this or that or decided to implement that or this.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  15. #30
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    3,798
    I've mentioned this elsewhere, but the C-preprocessor is the reason the C++ standard library headers look like such complete and total crap, because if you they weren't you could do "#define StrBuf lolitron;" before including iostream - then boom, textual substitution at the preprocessing level causes everything to explode. Hence underscoring things to hell and making them illegible and unreadable. And keep in mind the C++ standard specifies you must do this in order to avoid naming conflicts - Microsoft apparently write their C++ headers using an actually readable style, before running them through a name/identifier obfuscator on their side, the resulting files which they ship to developers for the Windows SDK (so you basically can't possibly clash names.)
    The standard reserves the leading underscore and uppercase letter combination for internal names precisely so that obfuscation is not a necessity.

    The standard does not mandate any obfuscation or particular implementation strategy. If an implementation "looks like such complete and total crap" it is not because of the standard or the C preprocessor. You only have the implementers to blame if you don't like some code.

    It doesn't matter if the headers represent a C++ standard library implementation or a font manipulation library, if you don't understand the design decisions and implementation strategy that resulted in a particular bit of code you have no business looking at the implementation.

    Wanting to help support a particular library is a fine thing, but you don't start by cracking open the code and spewing "This code sucks!" over everyone. Strangely enough, "you have no business being here" if that is how you are going to behave.

    Soma

Page 2 of 3 FirstFirst 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Java vs C to make an OS
    By WOP in forum Tech Board
    Replies: 59
    Last Post: 05-27-2007, 03:56 AM
  2. C#, Java, C++
    By incognito in forum A Brief History of Cprogramming.com
    Replies: 10
    Last Post: 10-05-2004, 02:06 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21