> Who's going to use a terabyte of hard drive space?
I could use it. For one thing, I'm an email packrat, and only delete my yahoo mail when I'm out of space. But a 1TB account would be useful for so much more than email. I think of it as free web-based storage. If I could get my hands on a free-for-life 1TB gmail account, I would whip up some code to encrypt and store arbitrary information as gmail messages. With the privacy concerns regarding gmail, encryption would be a necessity for using gmail in this fashion. A proper interface would allow gmail to look like an encrypted, web-based file system.
Also, it appears that there is a 10MB limit per message. No problem, just treat gmail as a harddrive with variable block sizes, up to 10MB. Storing larger files would simply mean splitting the file across multiple messages.
You guys are all behind the times. I'm already on E!
My languages are so advanced, they couldn't be referred to by letters from the English alphabet, so they use the Greek letter lambda. Give me Scheme or Haskell any day over C or D or whatever.
Sure, it's hard to do by hand. But I know of at least one compiler (Intel's C++ compiler) that can generate multiple versions of assembly code and dispatch on processor type at runtime. That compiler is much better than Visual Studio for numerical computation.
This book contains paddleball in something like 20 lines of code. The book's website provides the code in an archive, in the file Fal.lhs. It is mixed in with the rest of the code for the functional animation module; the version presented in the book itself shows just the paddleball portion. I found it very interesting that programs with this degree of complexity could be implemented with so little code.
I agree that if you want to allow other languages to interface with your C++ code, you write it differently. The thing is, with C++, this must be one of your design goals; if you write in C, your library is much more likely to be usable without an additional interface wrapper layer.
C++ as a programming language is perfectly portable
In theory, yes, but in practice, no. Quick, what happens if new fails? Does it return 0, or throw an exception? Well, it depends on your compiler.
The C++ standard is not supported by all C++ compilers; support is getting better, but it is not 100%. The October 2003 issue of Dr. Dobbs Journal included a C++ compiler comparison. Each compiler tested supported a different set of features. Many times, these are small differences, but since computers lack common sense, these differences become major stumbling blocks.
The inconsistency in C++ prompted the ACE designers to write a C++ compatibility layer that smooths out the differences in C++ compilers. If the C++ language were truly portable, this work would have been unnecessary.
The sad thing is, though it should run fine on a modern x86 processor, it is almost certainly slower than code that a decent C++ compiler with processor specific optimizations would produce. If the code had been written in C, it would be able to take advantage of MMX and SSE instructions with nothing but a recompile. I have seen hand-optimized assembly code for doing 64-bit arithmetic that was written a few years back; replacing this code by using __int64 and normal arithmetic operators resulted in a speedup.
It is relatively easy (as easy as with C) to create bindings for C++. And even if it wasn't, you can create C bindings for C++, so you could simply then create the bindings for other languages using the C layer.
The problem is in trying to make use of C++'s more advanced features, such as templates and classes, from some other language. Many C++ libraries depend upon the use of these features to function correctly. Mapping a C++ class heirarchy to some other language is almost sure to require a large amount of work. While I agree that a C binding can be created for a C++ library, this may not be a trivial task.
Consider, for example, trying to crate a C binding for STL vectors. Since C does not support templates, the work will not be easy. One option would be to create some kind of C preprocessor that could add generics to C; but this is exactly how C++ started in the first place (as a preprocessor). Another option is to create a pure C interface, then to implement that interface using vectors.
The problem is that there is a huge semaintic difference between C++ and C. Most languages include some sort of C interface, since C is low-level and an easy target for interoperability. Few languages come with support for interacting with C++. For interoperability, C's semantics are simple: just functions and data structures. Calling C functions from some other language usually boils down to just a wrapper for the function, along with appropriate marshalling code to convert data types. On the other hand, C++'s model of OOP is a one-of-a-kind. Higher level languages simply do not share C++'s view of OOP. While there are definitely similarities that are shared among most object-oriented languages, the differences are so wide as to make a general interface to C++ impossible.
It is at best stupid to talk about how 'C is dying' anyway, seeing as it is still the most popular language in many areas, as well as the single biggest inspirator for 'new' languages.
I agree 100% that C is the biggest inspirator for new languages. One can only take being burned by C's shortcomings so much before deciding that there has to be a better way.
> How in the world did something finish in first *and* third?
A previous poster mentioned
If you read the rules, the first place entry was determined by (votes total/bytes)
while second place was (votes total)
and third was (votes total/(bytes^2))
Given this strange judging criteria, it happened that Simple had the highest score for both votes total/bytes and votes total/bytes^2.
> OCaml... And I don't know why you call it "pseudo" functional
OCaml is not a pure functional language in that it allows for references to mutable objects. A pure functional language, such as Haskell, does not allow mutation or side effects in functions. In order to allow things like IO, Haskell uses monads, which essentially thread the mutable state through function calls in order to give the appearance of side effects without breaking the referential transparency offered by pure functional languages.
Slashdot Mirror
Nice sig.
I could use it. For one thing, I'm an email packrat, and only delete my yahoo mail when I'm out of space. But a 1TB account would be useful for so much more than email. I think of it as free web-based storage. If I could get my hands on a free-for-life 1TB gmail account, I would whip up some code to encrypt and store arbitrary information as gmail messages. With the privacy concerns regarding gmail, encryption would be a necessity for using gmail in this fashion. A proper interface would allow gmail to look like an encrypted, web-based file system.
Also, it appears that there is a 10MB limit per message. No problem, just treat gmail as a harddrive with variable block sizes, up to 10MB. Storing larger files would simply mean splitting the file across multiple messages.
My languages are so advanced, they couldn't be referred to by letters from the English alphabet, so they use the Greek letter lambda. Give me Scheme or Haskell any day over C or D or whatever.
Sure, it's hard to do by hand. But I know of at least one compiler (Intel's C++ compiler) that can generate multiple versions of assembly code and dispatch on processor type at runtime. That compiler is much better than Visual Studio for numerical computation.
You're asking that question on the wrong site.
This book contains paddleball in something like 20 lines of code. The book's website provides the code in an archive, in the file Fal.lhs. It is mixed in with the rest of the code for the functional animation module; the version presented in the book itself shows just the paddleball portion. I found it very interesting that programs with this degree of complexity could be implemented with so little code.
I agree that if you want to allow other languages to interface with your C++ code, you write it differently. The thing is, with C++, this must be one of your design goals; if you write in C, your library is much more likely to be usable without an additional interface wrapper layer.
In theory, yes, but in practice, no. Quick, what happens if new fails? Does it return 0, or throw an exception? Well, it depends on your compiler.
The C++ standard is not supported by all C++ compilers; support is getting better, but it is not 100%. The October 2003 issue of Dr. Dobbs Journal included a C++ compiler comparison. Each compiler tested supported a different set of features. Many times, these are small differences, but since computers lack common sense, these differences become major stumbling blocks.
The inconsistency in C++ prompted the ACE designers to write a C++ compatibility layer that smooths out the differences in C++ compilers. If the C++ language were truly portable, this work would have been unnecessary.
The sad thing is, though it should run fine on a modern x86 processor, it is almost certainly slower than code that a decent C++ compiler with processor specific optimizations would produce. If the code had been written in C, it would be able to take advantage of MMX and SSE instructions with nothing but a recompile. I have seen hand-optimized assembly code for doing 64-bit arithmetic that was written a few years back; replacing this code by using __int64 and normal arithmetic operators resulted in a speedup.
The problem is in trying to make use of C++'s more advanced features, such as templates and classes, from some other language. Many C++ libraries depend upon the use of these features to function correctly. Mapping a C++ class heirarchy to some other language is almost sure to require a large amount of work. While I agree that a C binding can be created for a C++ library, this may not be a trivial task.
Consider, for example, trying to crate a C binding for STL vectors. Since C does not support templates, the work will not be easy. One option would be to create some kind of C preprocessor that could add generics to C; but this is exactly how C++ started in the first place (as a preprocessor). Another option is to create a pure C interface, then to implement that interface using vectors.
The problem is that there is a huge semaintic difference between C++ and C. Most languages include some sort of C interface, since C is low-level and an easy target for interoperability. Few languages come with support for interacting with C++. For interoperability, C's semantics are simple: just functions and data structures. Calling C functions from some other language usually boils down to just a wrapper for the function, along with appropriate marshalling code to convert data types. On the other hand, C++'s model of OOP is a one-of-a-kind. Higher level languages simply do not share C++'s view of OOP. While there are definitely similarities that are shared among most object-oriented languages, the differences are so wide as to make a general interface to C++ impossible.
I agree 100% that C is the biggest inspirator for new languages. One can only take being burned by C's shortcomings so much before deciding that there has to be a better way.
A previous poster mentioned
Given this strange judging criteria, it happened that Simple had the highest score for both votes total/bytes and votes total/bytes^2.
> OCaml ... And I don't know why you call it "pseudo" functional
OCaml is not a pure functional language in that it allows for references to mutable objects. A pure functional language, such as Haskell, does not allow mutation or side effects in functions. In order to allow things like IO, Haskell uses monads, which essentially thread the mutable state through function calls in order to give the appearance of side effects without breaking the referential transparency offered by pure functional languages.