That's an excellent observation; I hadn't made the connection before but adapting the stories to the medium is particularly *appropriate* to Tolkien's work.
Sun's been a possible target for takeovers for a while, so I suspect that a big reason for GPL'ed Java and accoutrements was to poison the possibility of just such a move by MS.
Sure, but this is a flaw in the modularity of awt - image processing libraries should not be intertwined with GUI libraries. Instead, the GUI library should depend upon the image processing library, and not vice versa.
The central problem is that Sun has not gone far enough in creating limited profiles of Java - by properly modularizing the core libraries. There is no reason why awt and swing should be part of the minimal core of Java. The same thing can be said for System and perhaps even the threading and socket APIs. If the core of Java was sufficiently modular, then there would be no issues with Google specifying a subset of modules that are supported within their environment.
With any luck, this is something that Project Jigsaw will address - though I dearly wish that Sun had opted to adopt OSGI within the jvm instead of developing their own module system.
The combination of static typing, type inference and concise syntax for higher-order functions give you a lot that Groovy and Java just fall short on.
In Java's case, it's the simple fact that you can't reasonably implement HOF's like filter, map, etc. without using anonymous inner classes. If you use anonymous inner classes, you end up with a ratio of like 8:1 of boilerplate:relvant expressions. Believe me, I've tried it. If you want to see just how baroque it gets, take a look at functionaljava.org.
Groovy has HOF, but it's interpreted and it doesn't have real static types. So it's slower and you don't have nearly as much ability to do compile-time type checking.
Scala rocks. I've been using it for several months now building a $50M/year transaction processing system and I never want to go back to writing regular old Java again.
The problem with allowing null values to propagate into null pointer exceptions is that the exceptions can be unrelated to the point of failure. Say that I have a method that returns a File, or null if that file is not found. If I take the results of that method and store it in an object (or worse, an anonymous inner class closure) that isn't used until later, the resulting NPE cannot be reliably prevented unless every use of the . If the method returns an Option instead, I have to explicitly deal with the failure case at the point in program flow where the method returns. This is particularly useful when it's possible to specify a reasonable default.
To be clear, it's not that replacing null with an Option allows you to do anything that you couldn't otherwise do by checking for a null return type - it just means that the compiler forces you to think about what the behavior should be if no sensible result is returned. In an ordinary Java program, you're never quite sure which methods might return null, so the only way to be perfectly safe is to check the return value of every method call. This extra boilerplate makes code hideous. If, on the other hand, a library never returns null, then you can safely skip the null check and use the powerful features provided by Option to deal with missing results wherever they might be returned - and the compiler will force you to do so.
The line between when to throw a checked exception and when to return an Option is a bit blurry; in general I use exceptions to indicate unexpected failure, and Option for situations where a missing return value might be expected. A classic example of an appropriate use of Option would be looking up a value from a Map - of course, the Java Map interface specifies a return value of null for when a key isn't found, but a more sophisticated Map interface that returns Option (such as the one in Scala) makes for much cleaner program flow. In the following, assume that baz is a method that may also return no result (null in the first case, Option in the second.) Compare:
//java Map m =... String foo = m.get("bar") if (foo == null) {
return "gweep"; }
Well, at least if I return a type that explicitly requires you to extract the data that you want from it, it is clear that the possibility of not returning data exists. If I simply returned null, there would be no way that the function signature would indicate this, and hence it's much more likely to go unchecked.
Checked exceptions are in my mind a different sort of beast, since they circumvent the normal program flow. If I call a function returning Option, I can immediately bind it to another function returning Option and evaluate the result in one place. As part of this, I can provide sensible default values at any point along the chain. Exception handling is usually not nearly so clean.
I agree that eliminating the use of null altogether would be a great deal better - my original post was simply pointing out a good way to do so in programs that people are writing today, without waiting for the compiler writers to catch up (and without the endless hand-wringing that would occur were they actually to eliminate null.)
If they're not a developer at my company, that's not my problem.
If somebody in my company using my code isn't willing to do their job properly and handle failure cases, that's great. My boss will be happy to fire them and find a replacement, and we'll all be better off as a result.
I much prefer to write as many parts of my program as pure functions as possible. If null is one language hole that caused a billion errors, mutable variables in places that they shouldn't be (i.e. just about anywhere that's not related to IO) have probably caused 10x that number of problems. Functions that mutate their arguments in-place are EVIL.
If you use a sane class for references that could possibly be null (like Option (aka Maybe in haskell) then your compiler will *force* you to handle the null case.
This is where null went wrong, at least in statically typed languages: it's a hole in the type system that errors fall through into your program. When coding in Java, I make an explicit point to never return null from a method; if I have a situation where no reasonable return value might exist, I use the Option class from functionaljava.org and thus force the client to handle the possibility of the method not returning sensible data. Since Option obeys the monad laws, it's easy to chain together multiple things that might fail (with the bind or flatMap operations.)
And repealing the 17th would be portrayed by the media as a bad thing were such a movement to gain any momentum. That is because the media is now and always has been positively allergic to nuance.
News is important, but I have yet to figure out any model for news delivery under which news organizations do not become despicable.
There's one application where VOIP is significantly preferable to the standard cellular network: international calling. I can use a VOIP app to talk to my cousins in Australia for free; being able to walk around my house or sit at the local coffeeshop while doing so would be nice.
This isn't about style; it's about adding functionality to a nice little piece of hardware. My cell phone's practically an antique at this point, but I have no need to upgrade it because I don't talk on the phone much. My iPod is a great PDA; adding VOIP capability would just be icing on the cake.
Mercurachrome? I remember that stuff. Liquid fire that didn't seem to do a damn thing to help wound healing. I didn't realize it had been banned, though.
Maybe it was the playground lobby that got that through? I know I would have signed on to a ban when I was five.
I live in Colorado, so I'm familiar with the sorts of conditions you're talking about. I guess that I'm used enough to lousy driving conditions and rapid changes in weather that they don't bother me; I keep a lightweight shell with me in case of unpleasantness.
If the weather is so severe as to make travel dangerous, it's usually pretty obvious as it's happening. I'll look at a weather report before I head into the mountains, but that's about it.
Which is obviously critically important, because there's so much that they can do about it.
Honestly, I don't get what the big deal about TV weather reports is. I don't watch TV, so I see what the weather is like when I look out the window in the morning. This has never proved to be a problem.
I think that the key to long-term archival storage is that in the future, all storage will be live storage. There won't be dark rooms full of degrading tapes; as storage becomes cheaper and denser there's less need to actually take data offline for archive. If the data's online, it can be maintained more easily and erasure-coding setups ensure that if physical storage units die you can just plug in a new one and go on. Also, data can be stored in a distributed fashion, so you don't have to worry so much about something like a fire in the warehouse.
ClearCase appears to let you mechanize local management hierarchy and policy. If your manager -- and only your manager -- is authorized to commit code changes to the shipping base of code, ClearCase will let you describe that workflow and enforce it for you. For large organizations with a management fetish, this too is a "feature".
Of course, Git also supports this feature. In fact, if you're using Git in the normal distributed fashion where everyone pushes to their own public repositories and pulls from the master, it's the default behavior.
I mean, who has more of a management fetish than Linus? Of course, his idea of management is not horribly dysfunctional like you're suggesting...
Apparently you haven't been introduced to the 'git submodule' command? You can add modules (recursively) at any point in your source hierarchy. Such modules are entirely independent git repositories; all that's tracked in your base repo is the version of the checked-out modules.
Git's SVN gateway is principally useful for migrating projects hosted on subversion to git. The simple fact is that git's change history cannot accurately be represented in subversion, so transformations back and forth between the systems are lossy and painful.
Right, because geography is *such* an important factor in determining what is important in terms of a primary education.
Why should curricula vary based upon our arbitrary state and district lines? Why should it be the case that if you grow up in the wrong place, your education sucks because the local yokels think that the earth is 6000 years old and the Rapture is impending?
If the Department of Education has problems, let's talk about fixing those problems. Throwing the whole thing out in favor of a strictly local approach just means that in less educated areas of the country the dumb just get dumber and the smart kids get screwed.
The most important thing you can do as a manager, in my opinion, is to shield your programming staff from political nonsense and conflicting requirements from different parts of the organization. It is your job to figure out the scope of your projects and clearly communicate that scope, and then stay out of the way of your team and make sure nobody else disrupts them.
Also, you must be willing to dig through the bureaucracy to get answers quickly and accurately when your team demands them.
Finally, it is your job to get your team the environment and resources that they need to be most productive. If they need something and it's not in the budget or goes against the general organizational culture, it's your job to get it for them by hook or by crook.
Being a manager can be a terrible job, but if you can give your team the environment they need to produce great results, you can be a star both from the perspective of the team and the organization as a whole.
Thanks for the pointer to BIRT; I'm actually in just the situation you describe on a project I'm working on and BIRT looks quite reasonable for what I'm trying to do.
Right, because legislation has always stopped crime in the past.
As long as there is a demand, there will be a supply, even if you turn the whole world into a police state. And so long as providing that supply is illegal, there will be violence in proportion to the degree with which that prohibition is enforced. Look at Chicago during the prohibition era for an example. As soon as alcohol was forced into the black market, violence related to that market increased dramatically.
The thing about the legalize/regulate/tax strategy is that it can provide resources to help try to reduce demand in the first place. The demand for drugs will never go to zero, but it could be lower than it is now.
There are actually a few studies going on currently (now in Canada, previously in Switzerland) on heroin maintenance programs that have demonstrated reductions in criminal activity by study participants.
In any case, without a doubt, there will be individuals who will suffer. I've not seen any evidence that the number of people suffering due to drug abuse will be any higher than it is now, however. Despite all of the money and blood we've poured into the drug war, drug use has not slackened. So why keep going with something that has obviously failed? If drugs were regulated and taxed, it'd be much easier to provide better education and treatment programs.
If you look at what's going on in Mexico along the border right now, it's eminently obvious what the greatest benefit to decriminalization would be: instantaneously cutting off the funding for massive criminal enterprises. So even if individual junkies are still committing petty crimes to fund their habits, it'd be a major blow to the major crime syndicates, and even (dare I say it) many of the funders of terrorism.
Slashdot Mirror
That's an excellent observation; I hadn't made the connection before but adapting the stories to the medium is particularly *appropriate* to Tolkien's work.
Sun's been a possible target for takeovers for a while, so I suspect that a big reason for GPL'ed Java and accoutrements was to poison the possibility of just such a move by MS.
Sure, but this is a flaw in the modularity of awt - image processing libraries should not be intertwined with GUI libraries. Instead, the GUI library should depend upon the image processing library, and not vice versa.
The central problem is that Sun has not gone far enough in creating limited profiles of Java - by properly modularizing the core libraries. There is no reason why awt and swing should be part of the minimal core of Java. The same thing can be said for System and perhaps even the threading and socket APIs. If the core of Java was sufficiently modular, then there would be no issues with Google specifying a subset of modules that are supported within their environment.
With any luck, this is something that Project Jigsaw will address - though I dearly wish that Sun had opted to adopt OSGI within the jvm instead of developing their own module system.
The combination of static typing, type inference and concise syntax for higher-order functions give you a lot that Groovy and Java just fall short on.
In Java's case, it's the simple fact that you can't reasonably implement HOF's like filter, map, etc. without using anonymous inner classes. If you use anonymous inner classes, you end up with a ratio of like 8:1 of boilerplate:relvant expressions. Believe me, I've tried it. If you want to see just how baroque it gets, take a look at functionaljava.org.
Groovy has HOF, but it's interpreted and it doesn't have real static types. So it's slower and you don't have nearly as much ability to do compile-time type checking.
Scala rocks. I've been using it for several months now building a $50M/year transaction processing system and I never want to go back to writing regular old Java again.
The problem with allowing null values to propagate into null pointer exceptions is that the exceptions can be unrelated to the point of failure. Say that I have a method that returns a File, or null if that file is not found. If I take the results of that method and store it in an object (or worse, an anonymous inner class closure) that isn't used until later, the resulting NPE cannot be reliably prevented unless every use of the . If the method returns an Option instead, I have to explicitly deal with the failure case at the point in program flow where the method returns. This is particularly useful when it's possible to specify a reasonable default.
To be clear, it's not that replacing null with an Option allows you to do anything that you couldn't otherwise do by checking for a null return type - it just means that the compiler forces you to think about what the behavior should be if no sensible result is returned. In an ordinary Java program, you're never quite sure which methods might return null, so the only way to be perfectly safe is to check the return value of every method call. This extra boilerplate makes code hideous. If, on the other hand, a library never returns null, then you can safely skip the null check and use the powerful features provided by Option to deal with missing results wherever they might be returned - and the compiler will force you to do so.
The line between when to throw a checked exception and when to return an Option is a bit blurry; in general I use exceptions to indicate unexpected failure, and Option for situations where a missing return value might be expected. A classic example of an appropriate use of Option would be looking up a value from a Map - of course, the Java Map interface specifies a return value of null for when a key isn't found, but a more sophisticated Map interface that returns Option (such as the one in Scala) makes for much cleaner program flow. In the following, assume that baz is a method that may also return no result (null in the first case, Option in the second.) Compare:
Map m =
String foo = m.get("bar")
if (foo == null) {
return "gweep";
}
String bazed = baz(foo);
if (bazed == null) {
return "gweep";
} else {
return bazed;
}
val m : Map[String,String] =
return m.get("bar").flatMap(baz(_)).getOrElse("gweep")
Well, at least if I return a type that explicitly requires you to extract the data that you want from it, it is clear that the possibility of not returning data exists. If I simply returned null, there would be no way that the function signature would indicate this, and hence it's much more likely to go unchecked.
Checked exceptions are in my mind a different sort of beast, since they circumvent the normal program flow. If I call a function returning Option, I can immediately bind it to another function returning Option and evaluate the result in one place. As part of this, I can provide sensible default values at any point along the chain. Exception handling is usually not nearly so clean.
I agree that eliminating the use of null altogether would be a great deal better - my original post was simply pointing out a good way to do so in programs that people are writing today, without waiting for the compiler writers to catch up (and without the endless hand-wringing that would occur were they actually to eliminate null.)
If they're not a developer at my company, that's not my problem.
If somebody in my company using my code isn't willing to do their job properly and handle failure cases, that's great. My boss will be happy to fire them and find a replacement, and we'll all be better off as a result.
Hey, yeah! Let's go back to 1970!
I much prefer to write as many parts of my program as pure functions as possible. If null is one language hole that caused a billion errors, mutable variables in places that they shouldn't be (i.e. just about anywhere that's not related to IO) have probably caused 10x that number of problems. Functions that mutate their arguments in-place are EVIL.
If you use a sane class for references that could possibly be null (like Option (aka Maybe in haskell) then your compiler will *force* you to handle the null case.
This is where null went wrong, at least in statically typed languages: it's a hole in the type system that errors fall through into your program. When coding in Java, I make an explicit point to never return null from a method; if I have a situation where no reasonable return value might exist, I use the Option class from functionaljava.org and thus force the client to handle the possibility of the method not returning sensible data. Since Option obeys the monad laws, it's easy to chain together multiple things that might fail (with the bind or flatMap operations.)
And repealing the 17th would be portrayed by the media as a bad thing were such a movement to gain any momentum. That is because the media is now and always has been positively allergic to nuance.
News is important, but I have yet to figure out any model for news delivery under which news organizations do not become despicable.
There's one application where VOIP is significantly preferable to the standard cellular network: international calling. I can use a VOIP app to talk to my cousins in Australia for free; being able to walk around my house or sit at the local coffeeshop while doing so would be nice.
This isn't about style; it's about adding functionality to a nice little piece of hardware. My cell phone's practically an antique at this point, but I have no need to upgrade it because I don't talk on the phone much. My iPod is a great PDA; adding VOIP capability would just be icing on the cake.
Mercurachrome? I remember that stuff. Liquid fire that didn't seem to do a damn thing to help wound healing. I didn't realize it had been banned, though.
Maybe it was the playground lobby that got that through? I know I would have signed on to a ban when I was five.
I live in Colorado, so I'm familiar with the sorts of conditions you're talking about. I guess that I'm used enough to lousy driving conditions and rapid changes in weather that they don't bother me; I keep a lightweight shell with me in case of unpleasantness.
If the weather is so severe as to make travel dangerous, it's usually pretty obvious as it's happening. I'll look at a weather report before I head into the mountains, but that's about it.
Which is obviously critically important, because there's so much that they can do about it.
Honestly, I don't get what the big deal about TV weather reports is. I don't watch TV, so I see what the weather is like when I look out the window in the morning. This has never proved to be a problem.
I think that the key to long-term archival storage is that in the future, all storage will be live storage. There won't be dark rooms full of degrading tapes; as storage becomes cheaper and denser there's less need to actually take data offline for archive. If the data's online, it can be maintained more easily and erasure-coding setups ensure that if physical storage units die you can just plug in a new one and go on. Also, data can be stored in a distributed fashion, so you don't have to worry so much about something like a fire in the warehouse.
Of course, Git also supports this feature. In fact, if you're using Git in the normal distributed fashion where everyone pushes to their own public repositories and pulls from the master, it's the default behavior.
I mean, who has more of a management fetish than Linus? Of course, his idea of management is not horribly dysfunctional like you're suggesting...
Apparently you haven't been introduced to the 'git submodule' command? You can add modules (recursively) at any point in your source hierarchy. Such modules are entirely independent git repositories; all that's tracked in your base repo is the version of the checked-out modules.
Git's SVN gateway is principally useful for migrating projects hosted on subversion to git. The simple fact is that git's change history cannot accurately be represented in subversion, so transformations back and forth between the systems are lossy and painful.
Right, because geography is *such* an important factor in determining what is important in terms of a primary education.
Why should curricula vary based upon our arbitrary state and district lines? Why should it be the case that if you grow up in the wrong place, your education sucks because the local yokels think that the earth is 6000 years old and the Rapture is impending?
If the Department of Education has problems, let's talk about fixing those problems. Throwing the whole thing out in favor of a strictly local approach just means that in less educated areas of the country the dumb just get dumber and the smart kids get screwed.
The most important thing you can do as a manager, in my opinion, is to shield your programming staff from political nonsense and conflicting requirements from different parts of the organization. It is your job to figure out the scope of your projects and clearly communicate that scope, and then stay out of the way of your team and make sure nobody else disrupts them.
Also, you must be willing to dig through the bureaucracy to get answers quickly and accurately when your team demands them.
Finally, it is your job to get your team the environment and resources that they need to be most productive. If they need something and it's not in the budget or goes against the general organizational culture, it's your job to get it for them by hook or by crook.
Being a manager can be a terrible job, but if you can give your team the environment they need to produce great results, you can be a star both from the perspective of the team and the organization as a whole.
Thanks for the pointer to BIRT; I'm actually in just the situation you describe on a project I'm working on and BIRT looks quite reasonable for what I'm trying to do.
Cheers!
Right, because legislation has always stopped crime in the past.
As long as there is a demand, there will be a supply, even if you turn the whole world into a police state. And so long as providing that supply is illegal, there will be violence in proportion to the degree with which that prohibition is enforced. Look at Chicago during the prohibition era for an example. As soon as alcohol was forced into the black market, violence related to that market increased dramatically.
The thing about the legalize/regulate/tax strategy is that it can provide resources to help try to reduce demand in the first place. The demand for drugs will never go to zero, but it could be lower than it is now.
There are actually a few studies going on currently (now in Canada, previously in Switzerland) on heroin maintenance programs that have demonstrated reductions in criminal activity by study participants.
In any case, without a doubt, there will be individuals who will suffer. I've not seen any evidence that the number of people suffering due to drug abuse will be any higher than it is now, however. Despite all of the money and blood we've poured into the drug war, drug use has not slackened. So why keep going with something that has obviously failed? If drugs were regulated and taxed, it'd be much easier to provide better education and treatment programs.
If you look at what's going on in Mexico along the border right now, it's eminently obvious what the greatest benefit to decriminalization would be: instantaneously cutting off the funding for massive criminal enterprises. So even if individual junkies are still committing petty crimes to fund their habits, it'd be a major blow to the major crime syndicates, and even (dare I say it) many of the funders of terrorism.
This is not at all true if you expand your point of view to include other western democracies, and not just do regional comparisons within the U.S.