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.
/me wonders if it will turn out like VP8.
Originally Posted by Adak
Are you sure comparisons between file formats and languages are valid?
With regard to some things, yes. Specs, encoders/decoders (compilers in this case) should be the same.
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.
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.
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 ?
It's gaining enormous momentum in the academic arena. Much like Eiffel did.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.
... 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.
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?Let's not let them wind us up, like C++ needs defending.
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.)
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.
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.
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."
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.
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.
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/
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.
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.
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.
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.
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.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.
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.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.
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.)
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.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.
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.- 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.
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.3 different layered solutions to your problem. However you look at it, the programming language offers you the tools to do it.
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."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 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/
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).
Look up a C++ Reference and learn How To Ask Questions The Smart Way
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.
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?
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: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.
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:
The second is using std::array variant 1:Code:template<typename T, int N1, int N2> void AddVec(T (&Vec1)[N1], T (&Vec2)[N2]) { static_assert(N1 == N2); }
And the third is using std::array variant 2:Code:template<typename T, int N1, int N2> void AddVec(std::array<T, N1>& Vec1, std::array<T, N2>& Vec2) { static_assert(N1 == N2); }
Code:template<typename T> void AddVec(T & Vec1, T & Vec2) { static_assert(Vec1.size == Vec2.size); }
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?
Yes, but Google are not keeping this to themselves. They want other people to use it. Other people != Google.
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.
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.
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.
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.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.
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++.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.
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.
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.
The standard reserves the leading underscore and uppercase letter combination for internal names precisely so that obfuscation is not a necessity.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 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
