The new Java generics remove the complexity of C++. The complicated things about C++ templates are the stuff you can do with the type variables and the behaviour with non-pointer types. Java skips both of those.
In general, it's best to enforce at compile time everything you believe to be true of your code. Of course, you can either just ignore generics if you don't like them or use ArrayList (e.g.), which is equivalent to the old way.
The instances are created when the class is loaded, and there's only one copy of each value. It's essentially like you're using int constants, except they're pointer constants instead, so you can dereference them to get more information than just equality. It's essentially the same as
public class Season {
static public final Season spring = new Season();
static public final Season summer = new Season();
static public final Season fall = new Season();
static public final Season winter = new Season();
private Season() { } };
Except it's only one line, there are useful additional methods (like a toString), and you can use it in a switch statement.
I've been on some clever steel coasters, and I find them fun but not that exciting. I think they're just too smooth; you have the feeling of moving quickly in strange directions, but it's mainly just interesting, and doesn't have the same thrill as a ride that shakes you while it happens.
On the other hand, it's fun to get pictures of yourself on a steel coaster going down a big hill. Everybody else is screaming, and you're calming chatting with the person next to you.
The JDK1.5 features seem to be mostly syntactic sugar to make doing things the right (compiler-checked) way easier than doing them the wrong way. A few (autoboxing, e.g.) just make doing things the right way reasonable. I'm not entirely sure that the implicit iterator thing was unreasonable before (it only removes two statements, and it was hard to get them wrong other than typing "iteraotr", unless, perhaps, you accidentally call next a second time on the iterator), so that's the least interesting change.
On the unboxing issue, there's the annoying situation that you really ought to get a NullPointerException for consistency with the rest of the language, but it would be annoying to have it this way. Personally, I think you should be able to have something like "(m.get(word) : 0) + 1", where you say what value you want for null, and get a NPE if there's a null you didn't provide for (the colon is from ?:, of course).
They're actually objects (you can put them in collections, for instance), they can have fields, methods, and constructors, etc. It's just that the compiler takes care of creating the instances and all, plus you can use them in swtch statements because the compiler knows they're enumerated.
Evil thought: you could get relatively nice-looking static instances with methods if you combined enums with anonymous inner classes...
The problem with that is that spammers frequently do use valid sender, reply-to, and bounce-to addresses, just not their own addresses. The trick is to authenticate the mail as coming from the same person (or entity) who would receive a response. After all, if there's anything that spammers have a lot of, it's valid email addresses.
The main problem is that there are no trustworthy third parties. Any solution which requires that someone be certified by a third party is doomed, because third parties are either untrustworthy or not accessible to the masses.
What this proposal fails to take into account is the fact that the real problem is email without a valid and authentic return address. This return address could be fail to be able to receive actual mail, or may be a pseudonym, but it should exist, and sending email with a given address should use exactly the same capabilities as receiving email with that address.
This would mean that users would have to send email through their ISPs in order to use their ISP email address, but they could equally well send email with some other address if the MX record for that address pointed at them.
Of course, there is a trusted third party: the domain registrar. But this party is already used for practically everything else, including authenticating the receivers of email, so this isn't a new authority but simply additional consistency.
I don't know if this continues to be a problem, but the Tablet PC I tried was heavier and thicker than a laptop, not to mention paper. Of course, they'll eventually get to be light and thin, but they're presently behind PDAs, laptops, or paper, depending on the application.
Painting a picture and writing a program are, in fact, quite analogous, although he doesn't quite expand this analogy quite as far as he should. When you paint a picture, you sometimes start by doing a bit of research into what the thing you're going to paint looks like. This corresponds to reading about similar programs, communication standards, user expectations, and so forth. Next you may do studies, which correspond to writing pseudocode for the interesting parts. Notice that you don't write pseudocode for the parts that aren't, in some way, novel, or that you already understand well. Next you start sketching. This is different from studies because it's actually on the canvas you intend to use. You're putting down lines which will guide your hand when you're putting down paint later. In computer terms, you're writing interfaces and stubs. You expect to rewrite all of the code, but you'll keep many of the function declarations. It doesn't make sense to do this on paper or in a different language from the one you intend to use. It is convenient if the language doesn't require static types for this, and it's also convenient if it's trivial to write code that doesn't run but does compile. Finally, you actually start to use paint, and produce the work that people will actually see as the finished product. This corresponds to doing the final implementation. You fill out the stubs and so forth. When you're most of the way through this, it is helpful if you can turn on more checks in the compiler. Lack of static typing becomes a bit of a liability, since you've now worked out what the outlines are, and static typing essentially keeps you inside the lines. While you may decide to change types and such, you should be kept from doing so accidentally.
Of course, hacking also has similarities to architecture, where, in addition to the steps in painting, you will have to follow constraints which allow the result to stand up; painting doesn't have anything which corresponds to "it looks nice, but it falls down if you build it."
Their EULA doesn't prevent you from suing them (in the US, you can't forfeit this right even intentionally); it just prevents you from winning. But really, winning such a lawsuit would be about as bad for Microsoft as losing. They don't really want it do to become a matter of precedent and public record that, when using Microsoft software, you are exposing yourself to huge risks with no protection. It's in the fine print, but it hasn't so far been in the national headlines. On the other hand, if Microsoft loses or settles such a suit, that's just money, and they have plenty of that.
Which means that it would be a good idea for them to make part or all of those apps open source. If the company derives its advantages from running the tools, not selling them, they might as well give them away in hopes that someone else will improve them in a way that saves the company some development time.
Of course, the results will probably be scripts and libraries, rather than full applications, because the full applications are generally very company-specific.
It's more like refridgeration. You could can someone to install refridgeration, but, for most people, it's better to just buy a fridge and stick it in your kitchen. There aren't many parts you'll want to tune or replace, assuming that you buy one that initially works as advertized.
Small businesses should be able to get websites by looking at a catalogue to find one that they like, buying it, and filling in the blanks. Sure, there are a lot of things you have to get right when running a web site, but the technically savvy company can get them right before the small business buys it.
Yeah, but you have to then assign the addresses in the block. The IPv6 version uses the device's MAC address so that each device has a unique ad hoc address out of the box. Handy for groups where nobody's running DHCP and the people don't want to negotiate the addresses themselves.
You don't have a case or anything, and you wouldn't win if it went to trial, but you could sue some random guy, and most random guys would settle rather than have a trial. Especially if you've got a lot of money and could somehow work copyright infringement into it.
IPv6 has a class of addresses for ad hoc networks (i.e., you have three friends with laptops and an ethernet hub, sitting in a cafe. You plug the cables in. You have a working network, with addresses), and other such special-purpose addresses. So it would be a good mix with IPv6 for some situations, at least. First thing that comes to mind is a modern X terminal: display box with a SA1110, a high-end graphics card, a keyboard, a mouse, and a gigabit ethernet card, running an accelerated X server for any client on the local network using its IPv6 ad hoc address. You plug it in, give it network, and you have an extra display for any computer in the house with no need to interact with the display box at all.
That's the really interesting thing about this. Whether or not Microsoft is liable or should be, this case will actually give some real information about whether suing a software vendor can get you anywhere. With Open Source Software, you can sue some random guy, and he'll settle and pay you $12K over several years. With Microsoft, on the other hand... well, we'll see.
I doubt I'll actually change to having an IPv6 address any time soon because I already have my static IPv4 addresses. On the other hand, I'll start connecting to people with IPv6 addresses sometime soon without realizing it. It's also possible that I'll have new devices without IPv4 addresses that I'll get IPv6 addresses for.
Actually, does anyone have a simple test to see if I'm already able to connect to IPv6 addresses?
I actually have "screen" in my.profile, which saves typing that command every time. I also find it nice to have screen as the only interface to that machine; there's a pleasing continuity of interaction with it, like being logged in on the (console) virtual terminals whenever I sit down at the machine (by SSH). If you explicitly start screen, there's a prompt before you're in your screen session, which doesn't follow this illusion.
Oh, and I much prefer -x to -D -R; with -x, if you are using multiple machines to connect from, you can be connected from all of them. Also, if you want to use more than one of the virtual terminals on the remote machine at the same time, you can just make a second connection in a different window. Of course, there is also the amusing effect of having characters you type in one window also echoed on a window on a different machine.
If you use suitable applications, you can run X with no noticable lag on a 90 MHz Pentium that's also acting as a server. Sure, running X takes a top-of-the-line computer, but it's a top-of-the-line computer from 8 years ago. I've still got mine on the desk next to me; I'm not using it for my display any more only because it doesn't support a nice resolution with an 8 year old graphics card, and because, while X is blazingly fast, compilers are not.
Of course, you can't run OpenOffice on your 90 Mhz machines (not that it would be worth shipping anyway, if you found one), but that's not X's fault, and if you're considering a non-X system, you'll need all new apps anyway; might as well write them for X.
A lot of pages already contain a form tag, though, so it is sufficient to add one line to an existing document. You can crash IE with a 5 line document, or with one line in a document.
The sensible thing for IBM to do would be to mainly ignore the thing. It's not like they don't have lawyers on staff who are quite capable of beating SCO in their spare time in this case. And IBM does best if SCO either drops the charges or loses the suit, because it proves that Linux is free of the legal mess that UNIX became. This is good for IBM, because they support Linux. Of course, they could buy SCO and get the rights, but the rights are either worthless or bad PR or both.
If things get out of hand, they could hasten the process by countersuing, but it hasn't gotten to that stage quite yet.
You need some form of IPC between applications and the shared display. There's no good reason to make this network-opaque, since you don't lose anything by providing the option of sending the calls over a network, if necessary.
As someone who's actually written a reasonable amount of code directly for Xlib, it's not that bad. There are a few annoying things, but you can mostly just ignore them these days (allocating colors is hopeless, but almost everybody these days has a 32 or 24-bit TrueColor visual, so you can just ignore all the stuff about colors and visuals and do the obvious thing for pixel values). It could use a new set of drawing primitives (like, perhaps, the set from SVG), but the API is otherwise not bad. The font stuff is a mess, since there were quite a number of attempts which got in before things settled down. Different character encodings can go away, since there's Unicode which handles everything. And so forth.
I think an X12 which cut out the obsolete stuff and provided a complete and consistent specification again (so each font has an XFont, no matter exactly what mechanism is used to render it, and XDrawText will draw it). The server would be the same as X11, except that it would be specified to always have a 32-bit color visual, which the server would simulate if it was running on something that actually didn't have 32-bit color for some reason.
Today's news: Apple makes $100K in 18 hours selling files you can copy. The RIAA makes $12-17K in 3 years going after people who copy files. Hey, if the RIAA sues 13 students every day, maybe they can keep up...
Re:Patching has saved my hundreds of dollars
on
The Costs of Patching
·
· Score: 2, Funny
Pants are easy to patch, and well worth it. All of the Microsoft systems I've tried to patch have gotten really screwed up as soon as I stuck the needle through them...
I believe if you download the plug-in, install it, and then disable it, you won't get the link. At least, I did something like that and stopped getting those.
Slashdot Mirror
The new Java generics remove the complexity of C++. The complicated things about C++ templates are the stuff you can do with the type variables and the behaviour with non-pointer types. Java skips both of those.
In general, it's best to enforce at compile time everything you believe to be true of your code. Of course, you can either just ignore generics if you don't like them or use ArrayList (e.g.), which is equivalent to the old way.
The instances are created when the class is loaded, and there's only one copy of each value. It's essentially like you're using int constants, except they're pointer constants instead, so you can dereference them to get more information than just equality. It's essentially the same as
public class Season {
static public final Season spring = new Season();
static public final Season summer = new Season();
static public final Season fall = new Season();
static public final Season winter = new Season();
private Season() { }
};
Except it's only one line, there are useful additional methods (like a toString), and you can use it in a switch statement.
I've been on some clever steel coasters, and I find them fun but not that exciting. I think they're just too smooth; you have the feeling of moving quickly in strange directions, but it's mainly just interesting, and doesn't have the same thrill as a ride that shakes you while it happens.
On the other hand, it's fun to get pictures of yourself on a steel coaster going down a big hill. Everybody else is screaming, and you're calming chatting with the person next to you.
The JDK1.5 features seem to be mostly syntactic sugar to make doing things the right (compiler-checked) way easier than doing them the wrong way. A few (autoboxing, e.g.) just make doing things the right way reasonable. I'm not entirely sure that the implicit iterator thing was unreasonable before (it only removes two statements, and it was hard to get them wrong other than typing "iteraotr", unless, perhaps, you accidentally call next a second time on the iterator), so that's the least interesting change.
On the unboxing issue, there's the annoying situation that you really ought to get a NullPointerException for consistency with the rest of the language, but it would be annoying to have it this way. Personally, I think you should be able to have something like "(m.get(word) : 0) + 1", where you say what value you want for null, and get a NPE if there's a null you didn't provide for (the colon is from ?:, of course).
They're actually objects (you can put them in collections, for instance), they can have fields, methods, and constructors, etc. It's just that the compiler takes care of creating the instances and all, plus you can use them in swtch statements because the compiler knows they're enumerated.
Evil thought: you could get relatively nice-looking static instances with methods if you combined enums with anonymous inner classes...
The problem with that is that spammers frequently do use valid sender, reply-to, and bounce-to addresses, just not their own addresses. The trick is to authenticate the mail as coming from the same person (or entity) who would receive a response. After all, if there's anything that spammers have a lot of, it's valid email addresses.
The main problem is that there are no trustworthy third parties. Any solution which requires that someone be certified by a third party is doomed, because third parties are either untrustworthy or not accessible to the masses.
What this proposal fails to take into account is the fact that the real problem is email without a valid and authentic return address. This return address could be fail to be able to receive actual mail, or may be a pseudonym, but it should exist, and sending email with a given address should use exactly the same capabilities as receiving email with that address.
This would mean that users would have to send email through their ISPs in order to use their ISP email address, but they could equally well send email with some other address if the MX record for that address pointed at them.
Of course, there is a trusted third party: the domain registrar. But this party is already used for practically everything else, including authenticating the receivers of email, so this isn't a new authority but simply additional consistency.
I don't know if this continues to be a problem, but the Tablet PC I tried was heavier and thicker than a laptop, not to mention paper. Of course, they'll eventually get to be light and thin, but they're presently behind PDAs, laptops, or paper, depending on the application.
Painting a picture and writing a program are, in fact, quite analogous, although he doesn't quite expand this analogy quite as far as he should. When you paint a picture, you sometimes start by doing a bit of research into what the thing you're going to paint looks like. This corresponds to reading about similar programs, communication standards, user expectations, and so forth. Next you may do studies, which correspond to writing pseudocode for the interesting parts. Notice that you don't write pseudocode for the parts that aren't, in some way, novel, or that you already understand well. Next you start sketching. This is different from studies because it's actually on the canvas you intend to use. You're putting down lines which will guide your hand when you're putting down paint later. In computer terms, you're writing interfaces and stubs. You expect to rewrite all of the code, but you'll keep many of the function declarations. It doesn't make sense to do this on paper or in a different language from the one you intend to use. It is convenient if the language doesn't require static types for this, and it's also convenient if it's trivial to write code that doesn't run but does compile. Finally, you actually start to use paint, and produce the work that people will actually see as the finished product. This corresponds to doing the final implementation. You fill out the stubs and so forth. When you're most of the way through this, it is helpful if you can turn on more checks in the compiler. Lack of static typing becomes a bit of a liability, since you've now worked out what the outlines are, and static typing essentially keeps you inside the lines. While you may decide to change types and such, you should be kept from doing so accidentally.
Of course, hacking also has similarities to architecture, where, in addition to the steps in painting, you will have to follow constraints which allow the result to stand up; painting doesn't have anything which corresponds to "it looks nice, but it falls down if you build it."
Their EULA doesn't prevent you from suing them (in the US, you can't forfeit this right even intentionally); it just prevents you from winning. But really, winning such a lawsuit would be about as bad for Microsoft as losing. They don't really want it do to become a matter of precedent and public record that, when using Microsoft software, you are exposing yourself to huge risks with no protection. It's in the fine print, but it hasn't so far been in the national headlines. On the other hand, if Microsoft loses or settles such a suit, that's just money, and they have plenty of that.
Which means that it would be a good idea for them to make part or all of those apps open source. If the company derives its advantages from running the tools, not selling them, they might as well give them away in hopes that someone else will improve them in a way that saves the company some development time.
Of course, the results will probably be scripts and libraries, rather than full applications, because the full applications are generally very company-specific.
It's more like refridgeration. You could can someone to install refridgeration, but, for most people, it's better to just buy a fridge and stick it in your kitchen. There aren't many parts you'll want to tune or replace, assuming that you buy one that initially works as advertized.
Small businesses should be able to get websites by looking at a catalogue to find one that they like, buying it, and filling in the blanks. Sure, there are a lot of things you have to get right when running a web site, but the technically savvy company can get them right before the small business buys it.
Yeah, but you have to then assign the addresses in the block. The IPv6 version uses the device's MAC address so that each device has a unique ad hoc address out of the box. Handy for groups where nobody's running DHCP and the people don't want to negotiate the addresses themselves.
You don't have a case or anything, and you wouldn't win if it went to trial, but you could sue some random guy, and most random guys would settle rather than have a trial. Especially if you've got a lot of money and could somehow work copyright infringement into it.
IPv6 has a class of addresses for ad hoc networks (i.e., you have three friends with laptops and an ethernet hub, sitting in a cafe. You plug the cables in. You have a working network, with addresses), and other such special-purpose addresses. So it would be a good mix with IPv6 for some situations, at least. First thing that comes to mind is a modern X terminal: display box with a SA1110, a high-end graphics card, a keyboard, a mouse, and a gigabit ethernet card, running an accelerated X server for any client on the local network using its IPv6 ad hoc address. You plug it in, give it network, and you have an extra display for any computer in the house with no need to interact with the display box at all.
That's the really interesting thing about this. Whether or not Microsoft is liable or should be, this case will actually give some real information about whether suing a software vendor can get you anywhere. With Open Source Software, you can sue some random guy, and he'll settle and pay you $12K over several years. With Microsoft, on the other hand... well, we'll see.
I doubt I'll actually change to having an IPv6 address any time soon because I already have my static IPv4 addresses. On the other hand, I'll start connecting to people with IPv6 addresses sometime soon without realizing it. It's also possible that I'll have new devices without IPv4 addresses that I'll get IPv6 addresses for.
Actually, does anyone have a simple test to see if I'm already able to connect to IPv6 addresses?
I actually have "screen" in my .profile, which saves typing that command every time. I also find it nice to have screen as the only interface to that machine; there's a pleasing continuity of interaction with it, like being logged in on the (console) virtual terminals whenever I sit down at the machine (by SSH). If you explicitly start screen, there's a prompt before you're in your screen session, which doesn't follow this illusion.
Oh, and I much prefer -x to -D -R; with -x, if you are using multiple machines to connect from, you can be connected from all of them. Also, if you want to use more than one of the virtual terminals on the remote machine at the same time, you can just make a second connection in a different window. Of course, there is also the amusing effect of having characters you type in one window also echoed on a window on a different machine.
If you use suitable applications, you can run X with no noticable lag on a 90 MHz Pentium that's also acting as a server. Sure, running X takes a top-of-the-line computer, but it's a top-of-the-line computer from 8 years ago. I've still got mine on the desk next to me; I'm not using it for my display any more only because it doesn't support a nice resolution with an 8 year old graphics card, and because, while X is blazingly fast, compilers are not.
Of course, you can't run OpenOffice on your 90 Mhz machines (not that it would be worth shipping anyway, if you found one), but that's not X's fault, and if you're considering a non-X system, you'll need all new apps anyway; might as well write them for X.
A lot of pages already contain a form tag, though, so it is sufficient to add one line to an existing document. You can crash IE with a 5 line document, or with one line in a document.
The sensible thing for IBM to do would be to mainly ignore the thing. It's not like they don't have lawyers on staff who are quite capable of beating SCO in their spare time in this case. And IBM does best if SCO either drops the charges or loses the suit, because it proves that Linux is free of the legal mess that UNIX became. This is good for IBM, because they support Linux. Of course, they could buy SCO and get the rights, but the rights are either worthless or bad PR or both.
If things get out of hand, they could hasten the process by countersuing, but it hasn't gotten to that stage quite yet.
You need some form of IPC between applications and the shared display. There's no good reason to make this network-opaque, since you don't lose anything by providing the option of sending the calls over a network, if necessary.
As someone who's actually written a reasonable amount of code directly for Xlib, it's not that bad. There are a few annoying things, but you can mostly just ignore them these days (allocating colors is hopeless, but almost everybody these days has a 32 or 24-bit TrueColor visual, so you can just ignore all the stuff about colors and visuals and do the obvious thing for pixel values). It could use a new set of drawing primitives (like, perhaps, the set from SVG), but the API is otherwise not bad. The font stuff is a mess, since there were quite a number of attempts which got in before things settled down. Different character encodings can go away, since there's Unicode which handles everything. And so forth.
I think an X12 which cut out the obsolete stuff and provided a complete and consistent specification again (so each font has an XFont, no matter exactly what mechanism is used to render it, and XDrawText will draw it). The server would be the same as X11, except that it would be specified to always have a 32-bit color visual, which the server would simulate if it was running on something that actually didn't have 32-bit color for some reason.
Today's news: Apple makes $100K in 18 hours selling files you can copy. The RIAA makes $12-17K in 3 years going after people who copy files. Hey, if the RIAA sues 13 students every day, maybe they can keep up...
Pants are easy to patch, and well worth it. All of the Microsoft systems I've tried to patch have gotten really screwed up as soon as I stuck the needle through them...
I believe if you download the plug-in, install it, and then disable it, you won't get the link. At least, I did something like that and stopped getting those.