Of course, a lot of task that humans approach using intelligence or think they approach using intelligence does not actually require intelligence.
.
.
.
On the other hand, if you look at what the smartest 10% humans can do when they really think about something, there is no way to replicate that with weak AI. And strong AI is not even on the distant horizon.
That just sounds like the same backtracking over the years. Everything from shifting the goalposts, and making up adhoc definitions to try and define the problem away.
Most humans can't do what the 10% smartest can. And most of the 10% smartest can't do everything all the other people in that 10% can. If we were to head down your path of excuses, you may as well just get it over with and say humans aren't intelligent, which misses the point, really. Can computers do what humans do? Increasingly yes. That's all there is to it, and trying to fence off intelligence by adhoc redefinitions doesn't get away from that fact.
A lot of people have been trumpeting on about how computers will never be able to beat humans at poker. It's the same old song and dance. 1) Identify activity X that AIs can't do. 2) Attribute it to some made up quality that only all humans supposed possess. 3) AI beats humans. 4) "Well, what's so difficult about activity X? No one has ever claimed it was unachievable" 5) Restart process with activity X+1.
This is why private companies can never do infrastructure works that nation building requires, regardless of how many invisible-hand marketeers wish it were so.
That's the great part - bug counts are going to be far lower if you HAVE to have complete knowledge of what's going on.
Publish your solution to the halting problem and then we'll talk.
And you take that one-size-fits-all approach to everything you do, no matter what the language.
Coming from the person who obviously thinks everything should be written in C.
And seriously, awk?
Wow, you've seriously lost it in your old (mental) age. You tried to criticize me for supposedly only knowing one language. Then I proved you wrong. Instead of accepting that you come up with yet another non-sequitur. The fact I have used multiple languages to do what is needed is proof I don't have a one-size-fits-all approach.
Remember: YOU'RE the one who went of on a headless chicken rant about young'uns inventing new languages left right and center, but at the same time maintain the cognitive dissonance to also hate people who want to add new features to a language to avoid having to invent new languages all the time. Sort your own cognitive dissonance out first.
I'm done talking to you. This whole discussion has basically been about you being an old fuddy duddy who not only hates learning anything new, but wants people to stay stuck where you are. Here's an idea: FUCK OFF. Why are you even here? If someone wants to add to their language, IT DOESN'T AFFECT YOU.
Actually I find functional style programming is a much better application of runtime polymorphism than OO inheritance hierarchies are. As a library designer, all I need to do is to accept a function object that fits a specification. As a user of that library, I don't need to know anything about the library other than what function object to pass to it. I can put only the minimal state I need in that function object. That way, neither library designer, nor library user introduce any coupling between each other's types.
Check again. Template code is generated before the translation to machine language stage.
First, the "compile" stage is not just the code generation phase. The semantic analysis is pretty much part of the compile phase. Second, The type information preserved by templates can aid in the code optimization stage.
You need to know that the data is ordered properly, or bsort() won't give right results - and the compiler CANNOT know that.
Whoop de do. You can write a generic bsort in C++. You can write a generic algorithm anything. But please, keep missing the point as you keep doing.
C++ keeps inventing new features. It's one of the best examples of bloat going.
Hey, you can keep living in the stone age if you want. Things were simpler then in the good ol' days.
And you clearly don't understand templates if you claim that template code runs faster. All template code does is allow the precompiler
I don't understand templates? You're calling it a "precompiler". Templates don't run in the precompile stage. Macros run in the precompile (or preprocessor, rather) stage. Templates require the full type information that is generated as the compile process goes along. Preserving type information allows for checks and optimizations that are not possible with void pointers, or pointers in general.
generate code that could also be generated in other ways, such as by a script.
And yes template code does run faster because of the "generated code". THAT IS THE POINT. Not just a moment ago, you were decrying the creation of new languages blah blah, and here you are talking about writing scripts to generate code. Where do you think those new languages come from if not because of people like you who would rather do more work for little benefit because it fits into some extremist ideology?
As for sorting, you can write different sorting routines based on the data and needs that are faster than anything you'll find in std::sort.
In case you didn't know, TEMPLATES can choose different routines based on the data. That's the whole point of templates. eg, you can have a generalized copy-range function, but depending on the compile time type, have it choose a fast copy using compiler intrinsics. That's the point of the std::sort example. Not because std::sort is the one and only sort, but because it is a demonstration of templates. Templates provide the ability to have tailored optimal algorithms without having to keep writing zillions of slightly different interfaces, or use void pointers and lose type information.
RAII is wrong. It's sloppy. Stop drinking the kool-aid.
How would you know? Judging by our conversation, it's obvious you know nothing about it. You obviously stopped learning C++ long before the 98 standard, or you didn't bother to learn something properly.
I never used any sort of garbage collection or STL classes
You use garbage collection. You just stupidly write code that a machine could do for you because you have gross misunderstanding based on an unwillingness to learn.
Not needed, same as templates
Templates can make code faster than C code. Just compare std::sort to qsort. Templates allow high level optimizations not possible with pointer based "generic" code. Templates aren't needed, but they're better.
Call me when your *nix OS is written in c++ - then we'll talk.
Whatever. The compilers used to build those C Unixes are written in C++. GCC has been compiling as C++ for a while now, but you probably didn't want to know about it either.
same as all the modern build tools, the whole "we have a problem to solve that no language solves, so let's invent yet another language", shit like ruby, the gazillion javascript libraries, etc
We are talking about C++ here, so the whole "let's invent another language" doesn't EVEN apply here. But trust you to not bring up any points of relevance.
The great thing about C is that you can quite easily understand all of it. C++ can trip you up easily.
What I find though is that libraries written in C are harder to understand than C++. Compare qsort to std::sort. In qsort, I have to manually pass in sizes, counts and a function pointer. In std::sort, I just need to pass in a begin and end iterator. The "size" and "count" are all worked out for me at compile time, and uses the default "
So yes, you can easily understand C. But you can't easily get the gist of a program written in C.
It is harder to understand C++. But you can easily get the gist of a program written in C++, but without sacrificing performance.
YOU can't determine that since you don't determine when there are no more references to the code
Yes you can. Most things are not shared pointers, and shouldn't be shared pointers. Most C++ Standard Library objects are decidely NOT shared pointers but use RAII. Get with the times - that was the case since C++98, but apparently you won't bring yourself to accept it.
Hell, even in C++98, the "smart pointer" library type was auto_ptr, which is decidely NOT shared, and that's been superseded by unique_ptr, which is NOT shared, which was based on Boost's scoped_ptr, which is NOT shared. Keep staying stuck in your pre-98 knowledge
And you SHOULD write free() every time you write malloc().
Yes, you should, if you're writing malloc and free. But if a compiler can call the equivalent of free for you every time, why stupidly keep doing it yourself? I call "free" every time I "malloc" because I create and/or use types which make that happen automatically. AND THEY DO NOT SHARE REFERENCES. Get that through your head please.
Also, if UI frameworks are a mess, blame the authors.
No, UI frameworks written in C are a mess. Frameworks like Qt are just fine, WITHOUT the use of shared pointers. But, hey, keep ignoring that point because it's inconvenient. Even Linus changed his diving software from GTK to Qt, even though he hates C++. He could not find a UI framework he liked written in C, that's how bad it is.
It should always be possible to know with 100% certainty which piece of code "owns" the resource.
.
.
.
Allocate it in one place, use it, free it. Anything else is just begging for problems.
Yet tools like Valgrind exist because that's what C programmers need. In a perfect world, everything would work perfectly. You should be complaining about the world not being perfect.
Even Java runs faster if you expressly call the garbage collector when you're done
Yes, and even better is if I don't even need a garbage collector, especially a mark and sweep garbage collector because I'm NOT using shared resources almost all of the time.
C++ destructors are deterministic. It isn't that hard of a concept.
Having to write clean up code more than once, ie outside of a destructor, is excessive work. I can write a vector, with one destructor, knowing everywhere the vector is used, its destructor will get called when its scope has ended without me having to write it. Deterministic and an efficient use of my time.
Whereas with malloc, you have to write free every single time afterwards.
Do the maths.
And what about shared ownership? Very common pattern in user interfaces. Look at the mess C UI frameworks are with their manual reference counting.
Seriously, if in this day and age you can't understand that scope based resource management is deterministic, maybe you should seriously consider actually learning the concept.
Except Microsoft, Google, Facebook, Intel, Bloomberg, and many other companies are giving it more attention as the standard moves on. C++17 is on track, with all the major compilers having implemented most of the features already. Standardization is almost moving to become a mere formality, and most of the design and implementation testing is done at the compiler level years before the next standard.
As for ECMA-standardized C#, C++ is ISO standardized, and there's no possible patent threat with it.
You can free up non-critical code allocations early to avoid background gc impacting performance
Nothing in C++ stopping from doing that. That's what scope based resource management gives you automatically. In C++, you allocate in the precise scope you need it and when that scope ends it's freed for you. You don't even have to think about impacting gc performance. You kind of proved my point that a compiler just makes that easier while sacrificing none of your control.
or re-purpose already allocated memory in critical code to reduce overhead
Again, nothing in C++ stopping you from doing that. In fact, move and perfect forwarding makes it even easier to repurpose resources but without sacrificing the deterministic destruction. And you STILL don't have to waste time writing clean up code.
Because in many circumstances you can do it better.
None of yours were examples of that and in fact shows its better to leave it to the compiler because it's a waste of productivity in most cases.
And given the amount of access bounds and resource management errors in C code written today, it is a fact that it is not better to leave it to humans.
Why shouldn't you use volatile, especially if you're writing hardware interfacing code?
Most of the new C++ stuff actually reduces the "complexity" budget. Type deduction outside of function interfaces greatly simplifies most everyday code. I find using C++11 and 14 and then going back to C++98 or 03 or TR1 actually helped understand the older stuff without much effort.
Why would we want to do something the compiler can do? There is no bragging rights to stupidly doing what a compiler can do. I can know exactly the scope of some malloc'd buffer, but so can a wrapped type like a vector. Why would I possibly want to waste time writing and testing/valgrinding to make sure every malloc is freed when the compiler can automatically call the destructor for me?
The fact that the C++ committee still rejected Concepts shows they're not willing to add in any old feature because reasons.
Funny how other languages don't get shit for actually including parallelism, networking, GUI, XML, JSON, etc into their standard library.
At least in C++ if you don't need those libraries, you don't have to still download/install a huge runtime environment, or rely on online package managers that have to be up all the time.
Great. Now let's all write everything in VBScript because people are too scared to learn new stuff. Oh way, learning VBScript will be like learning new stuff!
The features he listed were not obscure. The expanded types of reference, move, and lambda functions are easy to grasp after one day of using it. In fact, most of the time you don't need to explicitly use it because the standard library constructs use it automatically.
Slashdot Mirror
How quickly people jump to the guy's defence.
Just use the one with the more clearer intent, unless it really affects performance.
Just keep in mind that familiarity is not the same as clarity.
Of course, a lot of task that humans approach using intelligence or think they approach using intelligence does not actually require intelligence.
.
.
.
On the other hand, if you look at what the smartest 10% humans can do when they really think about something, there is no way to replicate that with weak AI. And strong AI is not even on the distant horizon.
That just sounds like the same backtracking over the years. Everything from shifting the goalposts, and making up adhoc definitions to try and define the problem away.
Most humans can't do what the 10% smartest can. And most of the 10% smartest can't do everything all the other people in that 10% can. If we were to head down your path of excuses, you may as well just get it over with and say humans aren't intelligent, which misses the point, really. Can computers do what humans do? Increasingly yes. That's all there is to it, and trying to fence off intelligence by adhoc redefinitions doesn't get away from that fact.
A lot of people have been trumpeting on about how computers will never be able to beat humans at poker. It's the same old song and dance. 1) Identify activity X that AIs can't do. 2) Attribute it to some made up quality that only all humans supposed possess. 3) AI beats humans. 4) "Well, what's so difficult about activity X? No one has ever claimed it was unachievable" 5) Restart process with activity X+1.
Again, how is that a fail? That doesn't say anything about perpetual growth.
Why? Why must everything have perpetual growth to be successful?
I wouldn't call 25 million subscribers "failing".
This is why private companies can never do infrastructure works that nation building requires, regardless of how many invisible-hand marketeers wish it were so.
That's the great part - bug counts are going to be far lower if you HAVE to have complete knowledge of what's going on.
Publish your solution to the halting problem and then we'll talk.
And you take that one-size-fits-all approach to everything you do, no matter what the language.
Coming from the person who obviously thinks everything should be written in C.
And seriously, awk?
Wow, you've seriously lost it in your old (mental) age. You tried to criticize me for supposedly only knowing one language. Then I proved you wrong. Instead of accepting that you come up with yet another non-sequitur. The fact I have used multiple languages to do what is needed is proof I don't have a one-size-fits-all approach.
Remember: YOU'RE the one who went of on a headless chicken rant about young'uns inventing new languages left right and center, but at the same time maintain the cognitive dissonance to also hate people who want to add new features to a language to avoid having to invent new languages all the time. Sort your own cognitive dissonance out first.
I'm done talking to you. This whole discussion has basically been about you being an old fuddy duddy who not only hates learning anything new, but wants people to stay stuck where you are. Here's an idea: FUCK OFF. Why are you even here? If someone wants to add to their language, IT DOESN'T AFFECT YOU.
And YOU miss the point that a human, having better knowledge than the compiler can ever have
Which is why there are no bugs, ever.
You want one size fits all, because that's all you know.
Explain why I know Java, Javascript, Python, LISP, assembly, plain-C, REXX, awk etc
People like you are the reason that people think running Doom in a web browser is somehow cool
Why would a C++ programmer want Doom to run in a web browser?
If you're not using C++, then why are you complaining?
Actually I find functional style programming is a much better application of runtime polymorphism than OO inheritance hierarchies are. As a library designer, all I need to do is to accept a function object that fits a specification. As a user of that library, I don't need to know anything about the library other than what function object to pass to it. I can put only the minimal state I need in that function object. That way, neither library designer, nor library user introduce any coupling between each other's types.
Check again. Template code is generated before the translation to machine language stage.
First, the "compile" stage is not just the code generation phase. The semantic analysis is pretty much part of the compile phase. Second, The type information preserved by templates can aid in the code optimization stage.
You need to know that the data is ordered properly, or bsort() won't give right results - and the compiler CANNOT know that.
Whoop de do. You can write a generic bsort in C++. You can write a generic algorithm anything. But please, keep missing the point as you keep doing.
C++ keeps inventing new features. It's one of the best examples of bloat going.
Hey, you can keep living in the stone age if you want. Things were simpler then in the good ol' days.
And you clearly don't understand templates if you claim that template code runs faster. All template code does is allow the precompiler
I don't understand templates? You're calling it a "precompiler". Templates don't run in the precompile stage. Macros run in the precompile (or preprocessor, rather) stage. Templates require the full type information that is generated as the compile process goes along. Preserving type information allows for checks and optimizations that are not possible with void pointers, or pointers in general.
generate code that could also be generated in other ways, such as by a script.
And yes template code does run faster because of the "generated code". THAT IS THE POINT. Not just a moment ago, you were decrying the creation of new languages blah blah, and here you are talking about writing scripts to generate code. Where do you think those new languages come from if not because of people like you who would rather do more work for little benefit because it fits into some extremist ideology?
As for sorting, you can write different sorting routines based on the data and needs that are faster than anything you'll find in std::sort.
In case you didn't know, TEMPLATES can choose different routines based on the data. That's the whole point of templates. eg, you can have a generalized copy-range function, but depending on the compile time type, have it choose a fast copy using compiler intrinsics. That's the point of the std::sort example. Not because std::sort is the one and only sort, but because it is a demonstration of templates. Templates provide the ability to have tailored optimal algorithms without having to keep writing zillions of slightly different interfaces, or use void pointers and lose type information.
RAII is wrong. It's sloppy. Stop drinking the kool-aid.
How would you know? Judging by our conversation, it's obvious you know nothing about it. You obviously stopped learning C++ long before the 98 standard, or you didn't bother to learn something properly.
I never used any sort of garbage collection or STL classes
You use garbage collection. You just stupidly write code that a machine could do for you because you have gross misunderstanding based on an unwillingness to learn.
Not needed, same as templates
Templates can make code faster than C code. Just compare std::sort to qsort. Templates allow high level optimizations not possible with pointer based "generic" code. Templates aren't needed, but they're better.
Call me when your *nix OS is written in c++ - then we'll talk.
Whatever. The compilers used to build those C Unixes are written in C++. GCC has been compiling as C++ for a while now, but you probably didn't want to know about it either.
same as all the modern build tools, the whole "we have a problem to solve that no language solves, so let's invent yet another language", shit like ruby, the gazillion javascript libraries, etc
We are talking about C++ here, so the whole "let's invent another language" doesn't EVEN apply here. But trust you to not bring up any points of relevance.
The great thing about C is that you can quite easily understand all of it. C++ can trip you up easily.
What I find though is that libraries written in C are harder to understand than C++. Compare qsort to std::sort. In qsort, I have to manually pass in sizes, counts and a function pointer. In std::sort, I just need to pass in a begin and end iterator. The "size" and "count" are all worked out for me at compile time, and uses the default "
So yes, you can easily understand C. But you can't easily get the gist of a program written in C.
It is harder to understand C++. But you can easily get the gist of a program written in C++, but without sacrificing performance.
YOU can't determine that since you don't determine when there are no more references to the code
Yes you can. Most things are not shared pointers, and shouldn't be shared pointers. Most C++ Standard Library objects are decidely NOT shared pointers but use RAII. Get with the times - that was the case since C++98, but apparently you won't bring yourself to accept it. Hell, even in C++98, the "smart pointer" library type was auto_ptr, which is decidely NOT shared, and that's been superseded by unique_ptr, which is NOT shared, which was based on Boost's scoped_ptr, which is NOT shared. Keep staying stuck in your pre-98 knowledge
And you SHOULD write free() every time you write malloc().
Yes, you should, if you're writing malloc and free. But if a compiler can call the equivalent of free for you every time, why stupidly keep doing it yourself? I call "free" every time I "malloc" because I create and/or use types which make that happen automatically. AND THEY DO NOT SHARE REFERENCES. Get that through your head please.
Also, if UI frameworks are a mess, blame the authors.
No, UI frameworks written in C are a mess. Frameworks like Qt are just fine, WITHOUT the use of shared pointers. But, hey, keep ignoring that point because it's inconvenient. Even Linus changed his diving software from GTK to Qt, even though he hates C++. He could not find a UI framework he liked written in C, that's how bad it is.
It should always be possible to know with 100% certainty which piece of code "owns" the resource. . . . Allocate it in one place, use it, free it. Anything else is just begging for problems.
Yet tools like Valgrind exist because that's what C programmers need. In a perfect world, everything would work perfectly. You should be complaining about the world not being perfect.
Even Java runs faster if you expressly call the garbage collector when you're done
Yes, and even better is if I don't even need a garbage collector, especially a mark and sweep garbage collector because I'm NOT using shared resources almost all of the time.
C++ destructors are deterministic. It isn't that hard of a concept.
Having to write clean up code more than once, ie outside of a destructor, is excessive work. I can write a vector, with one destructor, knowing everywhere the vector is used, its destructor will get called when its scope has ended without me having to write it. Deterministic and an efficient use of my time.
Whereas with malloc, you have to write free every single time afterwards.
Do the maths.
And what about shared ownership? Very common pattern in user interfaces. Look at the mess C UI frameworks are with their manual reference counting.
Seriously, if in this day and age you can't understand that scope based resource management is deterministic, maybe you should seriously consider actually learning the concept.
Except Microsoft, Google, Facebook, Intel, Bloomberg, and many other companies are giving it more attention as the standard moves on. C++17 is on track, with all the major compilers having implemented most of the features already. Standardization is almost moving to become a mere formality, and most of the design and implementation testing is done at the compiler level years before the next standard.
As for ECMA-standardized C#, C++ is ISO standardized, and there's no possible patent threat with it.
You can free up non-critical code allocations early to avoid background gc impacting performance
Nothing in C++ stopping from doing that. That's what scope based resource management gives you automatically. In C++, you allocate in the precise scope you need it and when that scope ends it's freed for you. You don't even have to think about impacting gc performance. You kind of proved my point that a compiler just makes that easier while sacrificing none of your control.
or re-purpose already allocated memory in critical code to reduce overhead
Again, nothing in C++ stopping you from doing that. In fact, move and perfect forwarding makes it even easier to repurpose resources but without sacrificing the deterministic destruction. And you STILL don't have to waste time writing clean up code.
Because in many circumstances you can do it better.
None of yours were examples of that and in fact shows its better to leave it to the compiler because it's a waste of productivity in most cases. And given the amount of access bounds and resource management errors in C code written today, it is a fact that it is not better to leave it to humans.
Why shouldn't you use volatile, especially if you're writing hardware interfacing code?
Most of the new C++ stuff actually reduces the "complexity" budget. Type deduction outside of function interfaces greatly simplifies most everyday code. I find using C++11 and 14 and then going back to C++98 or 03 or TR1 actually helped understand the older stuff without much effort.
Why would we want to do something the compiler can do? There is no bragging rights to stupidly doing what a compiler can do. I can know exactly the scope of some malloc'd buffer, but so can a wrapped type like a vector. Why would I possibly want to waste time writing and testing/valgrinding to make sure every malloc is freed when the compiler can automatically call the destructor for me?
Only idiots brag about doing excessive work.
The fact that the C++ committee still rejected Concepts shows they're not willing to add in any old feature because reasons.
Funny how other languages don't get shit for actually including parallelism, networking, GUI, XML, JSON, etc into their standard library.
At least in C++ if you don't need those libraries, you don't have to still download/install a huge runtime environment, or rely on online package managers that have to be up all the time.
Great. Now let's all write everything in VBScript because people are too scared to learn new stuff. Oh way, learning VBScript will be like learning new stuff!
The features he listed were not obscure. The expanded types of reference, move, and lambda functions are easy to grasp after one day of using it. In fact, most of the time you don't need to explicitly use it because the standard library constructs use it automatically.