anonymous

2. That is an interesting point. Gut instinct says tmp should end up being f64 and then both expressions would be the same. Equally valid is the interpretation that the user selected explicitly for conversion to f32 of the intermediate value. We all know computers don't perform platonically perfect math with real numbers, there isn't much you can do about it, but I think the choice which results in the most precision should win at the end of the day.

Perhaps in a language which doesn't require specifying types like Rust, the best thing to do is to simply dispense with 32-bit floating point values entirely. I'd be equally happy with compiler flags like -fmore-precision. Or maybe you could have other arithmetic operators like +64 and +80 which cast all their arguments to 64/80-bit floating point numbers and produce a result with that precision. So I'd write

    let a: f32 = b (+80) c (/80) d as f32

It makes way more sense to me than carrying over the limitations of old (CRT) technology.

I do not understand why the[1] shell... which is a relatively small language... is so difficult for people to learn.

If you can find the time to learn Ruby, what stops you from learning a shell? What is the cost of ignoring it?

1. Preferably something resembling the proposed POSIX standard which might lend to portability. Bash is not necessarily the best choice unless every server you will ever use will be GNU userland/Linux kernel.

I have a question for you: "With respect to importing and exporting, how important is it to be in balance, or to have trade surplus (versus a trade deficit)?"

China's strategy is aimed at ensuring it maintains a trade surplus. They have succeeded for centuries. China will export more than it imports.

And the US? Its strategy is to look for the cheapest labor and goods to "exploit", whereever those may be found.

What do you think? Which is the better strategy? Does trade balance matter?

As for this article, I have no idea what this guy is on about.

The US is primarily a buyer. China is primarily a seller.

If you accept that as true, then the US's "credit" is important. And who do you think decides whether a buyer's credit is good?

Would you keep shipping goods to a buyer who could not pay?

On the other hand, a friend who spent a year in Japan remarked that, e.g. policemen carry dictionaries with them. When you need to carry around a book on how to write your own language because it has way too many complicated glyphs for everyday people to learn to 100%, maybe it's time for an orthographic reform.

    LS=$(ls)
    ./cruncher <<END
    $LS
    END
    ./muncher <<END
    $LS
    END

A more interesting idea would be if you do this for every user - prerender the page and send them the result, so they don't have to do the first, heavy js execution themselves. I know it sounds a bit retarded at first - you're basically using javascript as a server-side page renderer, but think about this: You can choose to prerender or not to prerender based on user agent string -- do it for people on mobile phones, but not for desktop users. You can write your entire site with just client-side page generation with javascript and let it run client-side at first, then switch to server-side prerendering once you have better hardware.

What? If you imply those are my initials, I'm sorry to say you're mistaken.

Kind of explains the popularity of thinkpads' nipple mouse, though.

1. completely backwards-compatible with ASCII

2. you can always tell if you're reading a part of a multibyte character or not, meaning that you can tell if you're reading a message that was cut in some random point and can tell how many bytes to drop before reaching the first start of a character

3. endian-agnostic due to being specified as a byte stream

4. contains no null bytes, so it can fit in any normal C string

Point 1 is absolutely vital for backwards-compatibility and 2 makes it better than a lot of other multibyte encodings. Consider for instance chopping one byte off the start of a ucs2-encoded string - you'll get complete garbage. And 3 means you don't get strange endian-related errors.

It's a robust, resilient encoding that's a drop-in replacement for ASCII and needs no special support from many utilities - tail and head for instance can work with UTF8 text as if it's plain ASCII, just looking for a \n byte and chopping the input in lines.

So yes, I do think it's elegant. It may not be the simplest possible encoding for unicode, but it's extremely practical.

Er.. just give me your IP and we're good to go, no? Even easier if you register a name for free on dyndns (for instance) and then give me something like mshaxxorette.homelinux.org.