Yea he mentions language features like interface-based polymophism, garbage collection, namespaces, first class functions, closures, etc. But then he goes on to talk about I/O methods, string manipulation, CSV output, etc. By which I think he means standard library features. The post really should have been split into language features + standard library features to make it clearer.
I may be influenced by the fact i'm into Go at the moment, but i think it covers most of the "features" he talks about, as well as many of the "libraries" (some may not be part of the standard library, but will be available through 3rd party packages). If the author is reading this, I encourage him to have a good honest look at http://golang.org/
I don't know if i like his discussion of "math-oriented types" vs. "machine-oriented types". At least as far as I see it (and according to wikipedia[1]), in maths whole integers (Z) are a subset of rational numbers (Q). When in your high-school maths class you say 3 + 2.5 = 5.5, you're really doing an implicit conversion to 3.0 + 2.5 = 5.5 or 3/1 + 5/2 = 11/2. Most languages allow you to also get rid of the bit-size of numbers by just defining "int" or "float" numbers that default to some predetermined bit-width (e.g. 32-bit). Most languages also have libraries or mechanisms (see Go and Python) for large precision numerical calculation so you can have your theoretically infinite size "no-overflow" situation; but that comes at the cost of speed, so we only use these types when it is specifically needed. It's not impossible to use them in all cases, but it is impractical.
In the end, a language can't do everything. Most languages focus on providing a good core, along with mechanism for users to extend functionality in any way they see fit. In this case I think the author wants the language to just do everything for him out of the box, without any pesky libraries, and without being bloated or slow. _That_ most certainly _is_ impossible. There is a good reason why no language implements _all_ of these "features".
Actually, from a math perspective, it's kind of nonsensical to talk about type conversion at all. That is, 3, 3.0, and 3/1 are purely notational differences, and all three represent exactly the same object. Since math is theoretically infinite precision, the way you write a number has no impact on the way operations like division act on it, making whether it belongs to Z, or just Q or R a moot point. Now, if you restrict your problem domain to Z, then that affects the operations you're able to do to a number and remain in that domain. That's more like what happens with types in programming; we restrict our domain by default because leaving the integers changes the computer's representation of the number in a way that affects its behavior.
Kind of. But you might say that rational numbers are ordered pairs of integers and positive integers, real numbers are Cauchy sequences of rationals, and complex numbers are ordered pairs of real numbers, and the real number 3 can't be added to (2+i) without converting it to a complex number first.
Those are all valid ways of conceptualizing those sets, but I don't think it changes the point I was making. The real number 3 doesn't need to be "converted" to a complex number to be added to 2+i. 3 is always both a real number and a complex number, which may be represented as either 3 or 3+0*i, and either way gives 5+i when added to 2+i. All the latter notation really does is clarifies what domain you're currently working in, and even so, I've never seen anyone write it out explicitly.
Type conversion is more like if you had the written number 3 and a picture of the point 5 on a number line and someone told you to add them. Naturally, you would write 5 as a number first, because you don't have a useful way to add a number and a picture. But this doesn't change the results of adding the quantities 3 and 5; it's purely an artifact of the way the information was presented to you.
A nice thing about John Conway's construction of the Surreal numbers is that integers are really a subset of the rationals, which are really a subset of the reals, which are really a subset of the surreals. I find this much more elegant than having "merely" finding an embedding of the smaller structure inside the larger one.
Wow, i didn't know any language had something like that. Can't say I'm surprised that it's a feature of Scheme/Lisp.
If OP said "Numerical Tower" in the first place I'd probably have looked it up and understood what he was talking about. Thanks for the info anyway. Learn something new every day on HN.
I may be influenced by the fact i'm into Go at the moment, but i think it covers most of the "features" he talks about, as well as many of the "libraries" (some may not be part of the standard library, but will be available through 3rd party packages). If the author is reading this, I encourage him to have a good honest look at http://golang.org/
I don't know if i like his discussion of "math-oriented types" vs. "machine-oriented types". At least as far as I see it (and according to wikipedia[1]), in maths whole integers (Z) are a subset of rational numbers (Q). When in your high-school maths class you say 3 + 2.5 = 5.5, you're really doing an implicit conversion to 3.0 + 2.5 = 5.5 or 3/1 + 5/2 = 11/2. Most languages allow you to also get rid of the bit-size of numbers by just defining "int" or "float" numbers that default to some predetermined bit-width (e.g. 32-bit). Most languages also have libraries or mechanisms (see Go and Python) for large precision numerical calculation so you can have your theoretically infinite size "no-overflow" situation; but that comes at the cost of speed, so we only use these types when it is specifically needed. It's not impossible to use them in all cases, but it is impractical.
In the end, a language can't do everything. Most languages focus on providing a good core, along with mechanism for users to extend functionality in any way they see fit. In this case I think the author wants the language to just do everything for him out of the box, without any pesky libraries, and without being bloated or slow. _That_ most certainly _is_ impossible. There is a good reason why no language implements _all_ of these "features".
[1] http://en.wikipedia.org/wiki/Set_(mathematics)
Ed: Z is a subset of Q.