The ability to call the destructor
closed account (EzwRko23)
Nothing xorebxebx has said has supported the original statement, unless the claim is that C++ is limited by the fact that it is imperative by nature and does not intrinsically support logic programming and functional programming at the same time. |
I was referring to the statement that C++ allows you freedom of choice more than any other modern language. In practice this freedom of choice is limited to imperative programming using manual memory mangement, cumbersome OO model tackled on C and some kind of generic metaprogramming based on textual substitution hack called "templates". This is a quite narrow subset of the programming domain - funny for so complex a language C++ is.
Scheme, LISP and Clojure are much simpler languages which support many more programming paradigms natively and are also much more expressive. If I'm not free to abstract away any detail of the algorithm to another black-box, my freedom is seriously limited. C++ repeatedly forces to overspecify solution of problems (which can be clearly seen in the LOC counts). You cannot run away from technical, low-level details and this is in most cases a bad thing.
Last edited on
closed account (z05DSL3A)
This is one hell of a dumb argument, different languages are different and do different things in different way and some languages are easier to do thing that they are design to do than others....
closed account (EzwRko23)
if you don't like C++, why are you here? |
I'm a counterweight for C++ fanboyism presented by some of the forum members, including you, jsmith :P
fanboyism, n.: The collective outlook and behavior of a group of people concerning a subject (movies, games, hardware, comic book characters, etc.) which when challenged results in an antagonistic, passionate, and unreasoned response. Rampant Fanboyism can be found on most internet message boards when such hot button subjects are discussed. You know a fanboy when you see one. Example: Fanboy 1: "Stupid people didn't get this movie" Fanboy 2: "If you didn't like the movie, you should'nt come here and trash it." |
Anyway, it is much more interesting to discuss things with someone who doesn't agree or has a different point of view. Besides, reading your 150+ LOC C++ equivalents of Scala one-liners is quite an entertaining thing.
different languages are different and do different things in different way and some languages are easier to do thing that they are design to do than others... |
The problem is, C++ doesn't excel even at the things it was designed to (systems programming). Most systems and embedded programming is still done in C or some stripped-down 20% subset of C++ (C with classes).
Last edited on
closed account (EzwRko23)
Troll.
You had better post it on a scala-user discussion list, to see how much courage and knowledge you really have to defend your statement. :P
You had better post it on a scala-user discussion list, to see how much courage and knowledge you really have to defend your statement. :P
Last edited on
| xorebxebx wrote: |
|---|
| Scheme, LISP and Clojure are much simpler languages which support many more programming paradigms natively and are also much more expressive. |
Functional languages have been around for much longer than imperative languages, and yet they are but mere curiosities in the language world. Very few significant programs are written in LISP and it has been around much longer than C++. Why do you suppose that is?
The functional programmer's response: "Because your average programmer is much too stupid to grasp the sheer power of <functional language of choice>."
The truth: the functional model is great for programming "in the small". They work great for trivial problems. But once you go beyond the trivial, they become completely unwieldy.
They are perfect for "here's a one-liner in <functional language of choice>". Look how elegant that is. The response should be: here's a 100,000-line mission-critical C++ or Java program, with another 100,000 lines of unit tests. How would you do that in <functional language of choice>?
The truth is you cannot.
The functional model is important to learn because it gives budding software engineers new insights into how software can be constructed. And the truth is that software engineers that truly "get" the functional programming model are generally more skilled than those that do not. But I will argue that functional languages just are not cut out for large-scale application development.
What does work is a multi-language approach: use functional languages or dynamic languages they way one does SQL. (Well, not *exactly* the way one uses SQL, but as a domain-specific language that helps get specific tasks done effeciently.)
| xorebxebx wrote: |
|---|
| The problem is, C++ doesn't excel even at the things it was designed to (systems programming). Most systems and embedded programming is still done in C or some stripped-down 20% subset of C++ (C with classes). |
BTW, Scala is good for domain-specific solutions, but it doesn't adequately adress the issue of multiple inheritance out of the box
http://www.qwantz.com/index.php?comic=1786
LOL
Last edited on
| the functional model is great for programming "in the small". They work great for trivial problems. But once you go beyond the trivial, they become completely unwieldy. |
Just want some elaboration on that topic, if possible.
I thought that c++ never had that ability. I thought they could only be invoked automatically whenever such and such an instance of a particular class went out of scope. Naw, really I remember reading that.
closed account (EzwRko23)
It's nice you stopped trolling and someone resorted back to arguments:
Scala supports exactly this kind of thing. It is many languages at once. E.g. You can have an SQL-like dialect in it, but still code imperatively if you wish.
I disagree. Scala's multiple inheritance is the answer to the problems of virtual inheritance in C++. Python took a similar approach. Scala's designers learn from failures of others.
This can be as well said about C++. This is a problem of all languages of higher-level than assembly. But in C++ it is even worse, because sometimes you cannot be sure even if you know the implementation - will the compiler apply RVO and eliminate the copying or not?
The question relies on the two false premises:
1. That functional languages have been around for much longer; not true - the first computers have been programmed in assembly and FORTRAN, then came LISP.
2. That functional languages are not used in significant projects. Actually, this might be true for pure functional, academic languages like Haskell. But there are plenty of functional-<something> hybrids like Ruby, OCaml, F#, Python, Scala, Erlang, R to name a few. The number of commercial, important projects done in these languages is high (actually Python's + Ruby's popularity seems to match C++'s popularity in open-source projects soon [1]). In some of them, these languages are used for mission-critical code, e.g. Erlang in the Open Telecommunications Framework or Scala in Twitter (yes, they chose Scala and not C++ despite the fact that performance is #1 on their requirements list). Also NASA considers using Scala or Python in their avionics software [2].
Many of the concepts that are researched in universities are first developed in some functional academic languages, and then some students take it and write a C or C++ programs basing on that algorithms (often as a homework) and then they bring it to the market. Doing research/prototyping in a language like C or C++ would be a waste of costly (human) resources.
This one is easy. It is enough to show just one counterexample. I'll show a few:
1. AutoCAD (LISP)
2. Emacs (LISP)
3. Open Telecommunication Framework (Erlang)
4. Yahoo Store (LISP)
5. LinkedIn (Scala + Java)
6. Twitter (Scala + Ruby)
7. CouchDB (Erlang)
It is exactly the opposite. How many 1M+ LOC systems have you built to support such (stupid) claim?
The fact is, although you can do large systems in imperative low level languages like C++, these systems easly break. Show me a large system that has availability of 99,9999999% (this means less than a second downtime per year) written in an imperative language with manual memory management. There is none. And Erlang can do that. C and C++ are good for writing small, embedded software or things were one crash per week is not a real problem - computer games, desktop applications etc.
What does work is a multi-language approach: use functional languages or dynamic languages they way one does SQL. (Well, not *exactly* the way one uses SQL, but as a domain-specific language that helps get specific tasks done effeciently.) |
Scala supports exactly this kind of thing. It is many languages at once. E.g. You can have an SQL-like dialect in it, but still code imperatively if you wish.
BTW, Scala is good for domain-specific solutions, but it doesn't adequately adress the issue of multiple inheritance out of the box http://www.qwantz.com/index.php?comic=1786 |
I disagree. Scala's multiple inheritance is the answer to the problems of virtual inheritance in C++. Python took a similar approach. Scala's designers learn from failures of others.
Because it's hard to predict exactly how long an operation (particularly a complex one) will take without knowing implementation details? |
This can be as well said about C++. This is a problem of all languages of higher-level than assembly. But in C++ it is even worse, because sometimes you cannot be sure even if you know the implementation - will the compiler apply RVO and eliminate the copying or not?
Functional languages have been around for much longer than imperative languages, and yet they are but mere curiosities in the language world. Very few significant programs are written in LISP and it has been around much longer than C++. Why do you suppose that is? |
The question relies on the two false premises:
1. That functional languages have been around for much longer; not true - the first computers have been programmed in assembly and FORTRAN, then came LISP.
2. That functional languages are not used in significant projects. Actually, this might be true for pure functional, academic languages like Haskell. But there are plenty of functional-<something> hybrids like Ruby, OCaml, F#, Python, Scala, Erlang, R to name a few. The number of commercial, important projects done in these languages is high (actually Python's + Ruby's popularity seems to match C++'s popularity in open-source projects soon [1]). In some of them, these languages are used for mission-critical code, e.g. Erlang in the Open Telecommunications Framework or Scala in Twitter (yes, they chose Scala and not C++ despite the fact that performance is #1 on their requirements list). Also NASA considers using Scala or Python in their avionics software [2].
Many of the concepts that are researched in universities are first developed in some functional academic languages, and then some students take it and write a C or C++ programs basing on that algorithms (often as a homework) and then they bring it to the market. Doing research/prototyping in a language like C or C++ would be a waste of costly (human) resources.
They are perfect for "here's a one-liner in <functional language of choice>". Look how elegant that is. The response should be: here's a 100,000-line mission-critical C++ or Java program, with another 100,000 lines of unit tests. How would you do that in <functional language of choice>? The truth is you cannot. |
This one is easy. It is enough to show just one counterexample. I'll show a few:
1. AutoCAD (LISP)
2. Emacs (LISP)
3. Open Telecommunication Framework (Erlang)
4. Yahoo Store (LISP)
5. LinkedIn (Scala + Java)
6. Twitter (Scala + Ruby)
7. CouchDB (Erlang)
The truth: the functional model is great for programming "in the small" |
It is exactly the opposite. How many 1M+ LOC systems have you built to support such (stupid) claim?
The fact is, although you can do large systems in imperative low level languages like C++, these systems easly break. Show me a large system that has availability of 99,9999999% (this means less than a second downtime per year) written in an imperative language with manual memory management. There is none. And Erlang can do that. C and C++ are good for writing small, embedded software or things were one crash per week is not a real problem - computer games, desktop applications etc.
Last edited on
| This can be as well said about C++. This is a problem of all languages of higher-level than assembly. But in C++ it is even worse, because sometimes you cannot be sure even if you know the implementation - will the compiler apply RVO and eliminate the copying or not? |
| 1. That functional languages have been around for much longer; not true - the first computers have been programmed in assembly and FORTRAN, then came LISP. |
| C and C++ are good for writing small, embedded software or things were one crash per week is not a real problem - computer games, desktop applications etc. |
closed account (EzwRko23)
But you can take steps to eliminate the ambiguity. If I need to write fast code, I'm going to avoid making copies even if I know that the implementation will prevent the copy. |
I doubt it. Very often to do so, at least in C++, you need to break API and touch more than the code that needs to be fast. Added the poor refactoring support you have got for C++, optimizing large stuff can be difficult and error-prone. Another thing you miss is that most of performance improvements come from algorithmic changes, not microoptimizations. Making algorithmic changes in languages that allow for composability is easier and safer.
Lisp is around one year younger than Fortran. For all intents and purposes, functional programming can be said to be as old as high level programming.Lisp is around one year younger than Fortran. |
assemblers - ~1950
Fortran - 1954
LISP - 1958
And operating systems. Just the world's infrastructure, nothing too big. |
Operating systems, at least the kernel parts which C is good for, are usually small and trivial.
There is nothing really complex there, no rocket science. You are talking about things that are ~5-100 kLOC, usually less than 5MB in compiled code. This doesn't count as a large system. And they are written mostly in pure C, not C++. If C++ were so grat at doing large __and__ reliable projects, noone would ever think of doing real-time trading systems in Java or designing new languages just for purposes of telecommunication systems.
Last edited on
| Very often to do so, at least in C++, you need to break API |
| Another thing you miss is that most of performance improvements come from algorithmic changes, not microoptimizations. |
| Fortran - 1954 LISP - 1958 |
Seriously, now.
| You are talking about things that are ~5-100 kLOC |
| And they are written mostly in pure C, not C++. |
| If C++ were so grat at doing large __and__ reliable projects [...] |
There are many applications where using C/++ is plain retarded. Nobody is arguing about that. But there are times when you absolutely have to squeeze all the juice out of the CPU, even if it means spending a lot of man hours, and there isn't enough clever notation to throw at the problem to will accomplish that. Sometimes you just need to have a wizard recite incantations at the processor.
closed account (EzwRko23)
We're discussing whether it's possible to know how long an operation will take. Don't change the subject. |
This is a tie. I can write hard-real time programs in Erlang or Java just as you can write them in C++. There is no fundamental difference. It is not possible to know how long a "new" call will take in the standard C++, just as "new" in the standard Java (except that new in Java is much faster and cache friendly).
I don't know what OS you're talking about, but it certainly isn't running on any desktop computer or server. The Linux kernel is over 3 MLOC, and the NT kernel is, or so I've heard, over 40 MLOC |
It is not. Drivers don't count. Especially drivers for all possible hardware ever.
Each driver is a separate module, it does not increase the complexity of the system. Drivers are quite simple. Well, as analogy, a static webpage serving a gallery with 100M photos is NOT ANY MORE complex than the webgallery serving 100 photos. But a static webpage with 1M photos is nowhere near Facebook complexity.
There are many applications where using C/++ is plain retarded. Nobody is arguing about that. But there are times when you absolutely have to squeeze all the juice out of the CPU, even if it means spending a lot of man hours, and there isn't enough clever notation to throw at the problem to will accomplish that. Sometimes you just need to have a wizard recite incantations at the processor. |
I think you missed the part where I've said "OR". C/C++ is great for small systems OR for [larger ones] if you can accept occasional crashes due to bugs. Well, it can be seen even in the compiler technology. It is easy to write a C compiler. Nowadays C compilers are probably bug-free. However, C++ compilers still crash sometimes, produce invalid code or don't conform to the specs. But hey, C++ compilers are much more complex. For every language there is some "critical mass" where you cannot create a reliable system. For functional languaegs this mass is much higher than for imperative ones. Especially for imperative ones with poor concurrency model (threads) and poor memory model (manual) which are two main causes for instability.
So I claim it is completely retarded to use C++ for **complex high availability** systems. It does not address complexity enough well. Simply the idea of the language where some random code can corrupt some random piece of memory does not play well with such systems.
Anyway - even those small OSes you mention are still full of buffer overruns, off-by-one errors, null dereference vulnerabilities etc. So, I doubt C/C++ is a good language to build them. In fact it would be much better to keep the C part as simple and small as possible and code the rest in HLL with proper security checking (this is what Microsoft does now with their Singularity OS, this is what OTF does). Linux and Windows are not 99,9999999% HA.
Last edited on
| This is a tie. |
| Each driver is a separate module, it does not increase the complexity of the system. |
| Well, as analogy, a static webpage serving a gallery with 100M photos is NOT ANY MORE complex than the webgallery serving 100 photos. But a static webpage with 1M photos is nowhere near Facebook complexity. |
| I think you missed the part where I've said "OR". C/C++ is great for small systems OR for [larger ones] if you can accept occasional crashes due to bugs. |
| Anyway - even those small OSes you mention are still full of buffer overruns, off-by-one errors, null dereference vulnerabilities etc. So, I doubt C/C++ is a good tool to build them. In fact it would be much better to keep the C part as simple and small as possible and code the rest in HLL with proper security checking (this is what Microsoft does now with their Singularity OS) |