Well, God is about the only entity which almost no one expects to do evil (or even bad by mistake). (And yes, this includes all atheists, because someone who doesn't exist can't do anything bad). Imagine the devil knows everything about you. Would you still feel comfortable?
As I imagine that is the purpose of Slashdot and as I started reading this discussion with that in mind, what would be a good solution to this problem?
Keep your cell phone switched off while you are not using it. Also, you might have several prepaid cards from different carriers and swap them regularly.
Yes. And you can readily indent your C, C++, Perl, Pascal, and even FORTRAN code. You can even do that automatically, in case your indentation got messed up. Try that with Python!
C cannot replace C++. You don't want to do manual resource management everywhere.
And yes, C++ does provide automation of memory management. Not GC, mind you, but RAII and a set of standard library classes which cover the most important cases.
There's generally no safety against two threads concurrently writing to the same container, nor against one thread writing and the other one reading. So an implementation with O(N) splice and O(1) size wouldn't have any concurrency problems. However the solution I suggested elsewhere in this thread (invalidate the size on splice() and recalculate on first subsequent call to size()) might indeed be costly to make thread safe (because logically size() is only reading and should therefore be thread safe). An option which doesn't have that problem would be to never recalculate after invalidating (so the first call on splice() would change size() to O(N) indefinitely, or at least until another mutating operation, like clearing the list, causes the size to be known again).
It's so easy it's not even sporting. You don't even need C++ for that.
// Suck that, bitches! #define true false
Bonus points for tucking it away into some build script as a compiler switch instead. Double bonus when build scripts are generated.
Or have a compiler wrapper somewhere which calls the real compiler with that option added, and make sure the build scripts find that instead of the real compiler while any direct compiler call finds the real compiler...
Does the simple statement: C++; open a temporary file, and record the number of increments or throw an exception?
Only if the programmer intentionally obfuscated the code. But then, he doesn't need operator overloading of #define; tell me, what does "increase_by_1(C);" do?
Oh, and if C is an int (or another incrementable builtin type), the statement C++; will indeed increment C, with certainty.
Some backwards progress like the idiotic narrowing errors in cases like { 1, 2 } for an array of floats.
They actually disallow implicit int to float conversion here? Heck, even Pascal allowed that conversion!
Actually I thing the conversion restrictions for new style initializations are wrong, despite the fact that I'm generally for more strict conversion rules (but not more strict than Pascal, mind you); but restricting them in such limited context breaks orthogonality.
However it could be solved with "partial tracking": Track the size until you encounter a splice, at which point you invalidate the tracked size (causing the next call to size, and only that, to be O(N)). People who never splice will have an O(1) size, people who do splice will have an O(1) splice. People who need size after splice will have to live with O(N), but they would have to in any case. Note however that only the first call to size after splice would be O(N), because after that the size is known again.
Please do tell which languages do you believe are "simpler (and arguably better" than C++.
error:Unexpected end of line.
You need to update your parser. The actual error is an unbalanced parenthesis in the quote. Except in poetry, line endings are not significant at all in the English language.
C is not better than C++. Quite the opposite: Most (not all, though) of C++'s problems are actually C problems. C is actually one of the worst languages I've ever seen. I cannot see why anyone would use C if he can use C++ and avoid at least the worst part of C.
Of the other languages: Scheme is definitely a great language (if one isn't allergic to parentheses:-)), however the fact that it is dynamically typed is a distinct disadvantage for larger programs.
Java IMHO is definitely not better than C++, period.
Ruby I don't have any experience with, so I cannot tell anything about it. However, AFAIK it's a scripting language, and thus not applicable to all problems.
Python I've up to now avoided to learn because I simply dislike dependence on amount of whitespace. The amount of whitespace is too fragile to depend on it.
But Perl was designed by a linguist. Is must be readable!:-)
(Actually from what I've seen from Perl 6, they've finally noticed that certain things like sigils changing by context just were a bad idea; unlike C++, they had the balls to be intentionally incompatible to get rid of those mistakes).
Well, he specifically said "above intro level." Yes, 99.9% of existing code will continue to work unmodified. However, best practices will change. For example, in C++03, a loop through a vector of ints would be coded like this (assuming you cannot or don't want to use std::for_each, which in C++03 is often a pain to use):
for(std::vector<int>::iterator iter = myvec.begin(), end = myvec.end(); iter != end; ++iter) { // use *iter to access the elements }
In C++0x, this still works, but no sane person would write that. They would write
for(auto& value: myvec) { // use value to access the elements }
or use the new lambdas with for_each:
std::for_each(myvec.begin(), myvec.end(), [](int& value) { // use value to access the elements });
Since when is.NET a language? It's a virtual machine with associated libraries. It is mostly programmed in the language C# (which is only available for.NET, but which is not.NET; indeed I guess the only reason why it isn't available apart from.NET is that nobody considers it worthwhile to port it to another platform), but.NET programs can also be written with VisualBasic.NET (which from what I hear is quite different from previous languages named "VisualBasic" and is also exclusively compiled to.NET) or C++/CLI (which, despite the name and what MS might tell you is a separate language based on C++, not just C++ with "language bindings" to.NET). There might also be other languages targetting.NET as well.
Try to use some more complicated template, make some unconscious mistake, and then try to find out at runtime WTF the error message means!!!!!
First: Templates are not OOP. That doesn't mean you cannot use templates with OOP, but they are as much OOP as C++ ints are OOP (you'll nevertheless use them in OOP in C++). The most template-heavy part of C++, the STL, is exactly the opposite of OOP (while OOP combines data and operations, STL separates them as fas as possible). Indeed, one of the primary authors of the STL, Alexander Stepanov, has publicly expressed his dislike of object orientation.
Also note that the templates you'll use in conjunction with OOP will typically be extremely simple, and thus not give you those complex error messages. It's when doing generic programming, generative programming or template metaprogramming when you write complicated templates and thus have to deal with those error messages.
You have to know both. Yes, Assembly isn't well suited to solving problems in it. But then, you are not learning assembly in order to better solve problems (well, unless you need the last bit of speed which you cannot get even from decent compilers, but that's the rare exception). You learn assembly to better understand how your solutions in a higher level language will be executed on the computer. You learn to understand why certain ideas which look nice in theory are just non-starters in practice. You learn to understand why it matters what is your outer loop and what your inner loop, even though your algorithm doesn't depend on it. You learn why the order of the fields in your data structures may matter.
Well, C++ isn't really an argument because here the main problem is the archaic header file model, which just doesn't fit modern programming methods.
And the hierarchy problem you mention is in part due to bad design (needlessly deep object hierarchies), in part due to an insufficient adaption of OOP to static typing (dynamically typed languages don't have that problem; AFAIK OOP was originally implemented with dynamical typing), esp. that you are forced to declare all supported interfaces at class declaration time (and yes, I don't know a statically typed language that doesn't have that problem; nevertheless it's not a fundamantal problem of OOP, as dynamically typed languages show, and IMHO even solvable for statically typed languages), and in part the classic interface mismatch problem which is completely independent from OOP (if you have to use two interfaces together which don't really match, you have to write an adapter; it doesn't matter if the mismatch is in object interfaces, in library APIs, or whereever; for example, if a sorting library expects a less-than function, but the library providing what you want to sort provides a three-way compare, then you must adapt the interfaces by writing the less-than function the sorting library needs using the three-way compare the data type library provides, no objects involved here).
When you write proper OOP, you have a whole building set up, with methods, classes, and stuff.
So you say it's only "proper" OOP if you build a complete framework? Well, then maybe my idea of OOP isn't exactly proper... maybe I've gotten too little OOP evangelization:-)
Slashdot Mirror
So what if you bring your phone to an airplane?
Well, God is about the only entity which almost no one expects to do evil (or even bad by mistake). (And yes, this includes all atheists, because someone who doesn't exist can't do anything bad).
Imagine the devil knows everything about you. Would you still feel comfortable?
Actually, with the European billing system all you need to know is the provider you were using.
They can safely discard any location data they collect while I'm not using the phone.
Are you sure? I would think that committing a crime and paying someone to commit the crime are two different crimes. IANAL, however.
Keep your cell phone switched off while you are not using it.
Also, you might have several prepaid cards from different carriers and swap them regularly.
Pah, googling for them will certainly only give you those which are favourable for Google! :-)
Python's idiotic indentation nonsense
Readability counts.
Yes. And you can readily indent your C, C++, Perl, Pascal, and even FORTRAN code.
You can even do that automatically, in case your indentation got messed up. Try that with Python!
C cannot replace C++. You don't want to do manual resource management everywhere.
And yes, C++ does provide automation of memory management. Not GC, mind you, but RAII and a set of standard library classes which cover the most important cases.
There's generally no safety against two threads concurrently writing to the same container, nor against one thread writing and the other one reading. So an implementation with O(N) splice and O(1) size wouldn't have any concurrency problems. However the solution I suggested elsewhere in this thread (invalidate the size on splice() and recalculate on first subsequent call to size()) might indeed be costly to make thread safe (because logically size() is only reading and should therefore be thread safe). An option which doesn't have that problem would be to never recalculate after invalidating (so the first call on splice() would change size() to O(N) indefinitely, or at least until another mutating operation, like clearing the list, causes the size to be known again).
It's so easy it's not even sporting. You don't even need C++ for that.
Bonus points for tucking it away into some build script as a compiler switch instead. Double bonus when build scripts are generated.
Or have a compiler wrapper somewhere which calls the real compiler with that option added, and make sure the build scripts find that instead of the real compiler while any direct compiler call finds the real compiler ...
Only if the programmer intentionally obfuscated the code. But then, he doesn't need operator overloading of #define; tell me, what does "increase_by_1(C);" do?
Oh, and if C is an int (or another incrementable builtin type), the statement C++; will indeed increment C, with certainty.
They actually disallow implicit int to float conversion here?
Heck, even Pascal allowed that conversion!
Actually I thing the conversion restrictions for new style initializations are wrong, despite the fact that I'm generally for more strict conversion rules (but not more strict than Pascal, mind you); but restricting them in such limited context breaks orthogonality.
Well, that's not 100% true: Exception specifications got deprecated in favour of noexcept.
However it could be solved with "partial tracking": Track the size until you encounter a splice, at which point you invalidate the tracked size (causing the next call to size, and only that, to be O(N)). People who never splice will have an O(1) size, people who do splice will have an O(1) splice. People who need size after splice will have to live with O(N), but they would have to in any case. Note however that only the first call to size after splice would be O(N), because after that the size is known again.
Please do tell which languages do you believe are "simpler (and arguably better" than C++.
error:Unexpected end of line.
You need to update your parser. The actual error is an unbalanced parenthesis in the quote. Except in poetry, line endings are not significant at all in the English language.
C is not better than C++. Quite the opposite: Most (not all, though) of C++'s problems are actually C problems. C is actually one of the worst languages I've ever seen. I cannot see why anyone would use C if he can use C++ and avoid at least the worst part of C.
Of the other languages: :-)), however the fact that it is dynamically typed is a distinct disadvantage for larger programs.
Scheme is definitely a great language (if one isn't allergic to parentheses
Java IMHO is definitely not better than C++, period.
Ruby I don't have any experience with, so I cannot tell anything about it. However, AFAIK it's a scripting language, and thus not applicable to all problems.
Python I've up to now avoided to learn because I simply dislike dependence on amount of whitespace. The amount of whitespace is too fragile to depend on it.
But Perl was designed by a linguist. Is must be readable! :-)
(Actually from what I've seen from Perl 6, they've finally noticed that certain things like sigils changing by context just were a bad idea; unlike C++, they had the balls to be intentionally incompatible to get rid of those mistakes).
Well, he specifically said "above intro level." Yes, 99.9% of existing code will continue to work unmodified. However, best practices will change. For example, in C++03, a loop through a vector of ints would be coded like this (assuming you cannot or don't want to use std::for_each, which in C++03 is often a pain to use):
In C++0x, this still works, but no sane person would write that. They would write
or use the new lambdas with for_each:
Maybe that's because it pretty much was the first language, well if you don't count machine code and assembler.
And Plankalkül.
Since when is .NET a language? It's a virtual machine with associated libraries. It is mostly programmed in the language C# (which is only available for .NET, but which is not .NET; indeed I guess the only reason why it isn't available apart from .NET is that nobody considers it worthwhile to port it to another platform), but .NET programs can also be written with VisualBasic.NET (which from what I hear is quite different from previous languages named "VisualBasic" and is also exclusively compiled to .NET) or C++/CLI (which, despite the name and what MS might tell you is a separate language based on C++, not just C++ with "language bindings" to .NET). There might also be other languages targetting .NET as well.
Try to use some more complicated template, make some unconscious mistake, and then try to find out at runtime WTF the error message means!!!!!
First: Templates are not OOP. That doesn't mean you cannot use templates with OOP, but they are as much OOP as C++ ints are OOP (you'll nevertheless use them in OOP in C++). The most template-heavy part of C++, the STL, is exactly the opposite of OOP (while OOP combines data and operations, STL separates them as fas as possible). Indeed, one of the primary authors of the STL, Alexander Stepanov, has publicly expressed his dislike of object orientation.
Also note that the templates you'll use in conjunction with OOP will typically be extremely simple, and thus not give you those complex error messages. It's when doing generic programming, generative programming or template metaprogramming when you write complicated templates and thus have to deal with those error messages.
You have to know both.
Yes, Assembly isn't well suited to solving problems in it. But then, you are not learning assembly in order to better solve problems (well, unless you need the last bit of speed which you cannot get even from decent compilers, but that's the rare exception). You learn assembly to better understand how your solutions in a higher level language will be executed on the computer. You learn to understand why certain ideas which look nice in theory are just non-starters in practice. You learn to understand why it matters what is your outer loop and what your inner loop, even though your algorithm doesn't depend on it. You learn why the order of the fields in your data structures may matter.
Well, C++ isn't really an argument because here the main problem is the archaic header file model, which just doesn't fit modern programming methods.
And the hierarchy problem you mention is in part due to bad design (needlessly deep object hierarchies), in part due to an insufficient adaption of OOP to static typing (dynamically typed languages don't have that problem; AFAIK OOP was originally implemented with dynamical typing), esp. that you are forced to declare all supported interfaces at class declaration time (and yes, I don't know a statically typed language that doesn't have that problem; nevertheless it's not a fundamantal problem of OOP, as dynamically typed languages show, and IMHO even solvable for statically typed languages), and in part the classic interface mismatch problem which is completely independent from OOP (if you have to use two interfaces together which don't really match, you have to write an adapter; it doesn't matter if the mismatch is in object interfaces, in library APIs, or whereever; for example, if a sorting library expects a less-than function, but the library providing what you want to sort provides a three-way compare, then you must adapt the interfaces by writing the less-than function the sorting library needs using the three-way compare the data type library provides, no objects involved here).
So you say it's only "proper" OOP if you build a complete framework? Well, then maybe my idea of OOP isn't exactly proper ... maybe I've gotten too little OOP evangelization :-)