Except, of course, that it's the family of the victims who are suing, and whom we might reasonably cut a little slack, not the parents of the shooters.
Basically, yes. You can never convert an integral value (1, 3, whatever) into an enumerator (Red, Green, whatever) without an explicit cast. This includes passing parameters to functions expecting an enumerator, returning enumerators from a function, assigning to a variable of an enumerated type, etc.
On the other side of the coin, the victim might not be concerned about deep pockets. Instead, the victim is most likely in deep pain and may be under the impression the stopping the game company from making such games might also stop this pain from happening again.
That's exactly the right take on this, IMHO. Shortly after the loss of a loved one, it's going to be difficult for anyone to be completely rational and objective. How about cutting them a little slack and dropping the cynicism for once?
You're half-right. An enumerator can be implicitly converted to an integral value, but not the other way around. You have to cast explicitly if you want to turn any other type of value into an enumerator.
Biometrics still have a lot of basic advantages over passwords.
Today:
[Informed cracker dials front desk]
Cracker: Hi, this is John in Support. We're having a problem with your account, could you just confirm the ID and password you use to log in so I can fix it up?
Clueless front desker: Sure, I type johndoe and the password is "reindeer flotilla".
Cracker: Great, thanks. I'll fix your account up right now, and you shouldn't see any difference from usual once it's done.
Next year:
[Informed cracker dials front desk]
Cracker: Hi, this is John in Support. We're having a problem with your account, could you just send me your fingerprint so we can fix it?
Clueless front-desker: Um...
Remember, the two biggest problems with passwords are (a) choosing dumb ones allowing brute-force attacks on a system, and (b) their vulnerability to social engineering attacks. Even simple biometrics would go a long way to fixing those, and thus restricting cracking to those who actually have a clue and not s'kiddies with nothing better to occupy their time.
I get password rage myself, although it is caused by moronic users who can't remember their passwords.
You don't, by any chance, insist that all passwords consist of a minimum of 27 characters, of which no more than 17 may be alphabetic (but those are case-sensitive) and 40% of the non-alphabetic characters must be punctuation rather than digits, and then make them change to a different hard-to-remember password every five minutes, do you?;-)
As others have noted, retrofitting some sort of automated testing would be very hard, but can be well worth it in the long run, maybe even this late in a development.
The key ingredients of successful automated test suites I've seen are...
Some sort of macro language that:
describes the inputs your program accepts (from a UI or otherwise)
is recordable by your program
is replayable by your program;
Some sort of state record that can be:
generated at any given point in your program by a macro
checked against when replaying that macro.
Given the above, all you need is a set of macros and a record of the state that should result, perhaps generated by that macro. (You probably want to record some sort of summary of the state that's likely to reflect as small a change in your state as possible, rather than the full state; often it's the fact that something has changed that is important, not the specifics of what the change was.) Then just replay all the macros and compare the state produced by your current program with the recorded, known-good states, and investigate any discrepancies.
Obviously writing an engine to do these things can be a very significant amount of work. For UI code, particularly if you're using a heavily message-based architecture, it's probably easiest to put the macros in at the message level, IME, which at least gives you a relatively easy way to replay those macros later.
As you can see, we've had our eye on you for some time now, Master of Transhuman. It seems you've been living two lives. In one life, you are a program writer using a respectable development platform. You have a social security number. You pay your taxes. You help your landlady carry out her garbage. The other life is lived on Slashdot, where you go by a hacker alias, advocate the use of a substandard platform, and are guilty of virtually every computer crime Redmond has sponsored a law for. One of these lives has a future, the other does not...
Re:Java's not exactly pining for the fields just n
on
Java vs .NET
·
· Score: 1
Compile and Continue is state of the art in java since 2 years, minimum.
That long, huh?
There are some areas where Visual Studio is behind its competitors. The debugger is not one of them.
Portability of platform vs. choice of language
on
Java vs .NET
·
· Score: 1
I think it's worth bearing in mind the relative productivity of different languages for different tasks.
One of the big selling points of the.Net architecture is that you can realistically write the high level functions of your program in genuinely high level languages, and then use the architecture to communicate with lower-level languages where high performance or refined control is more critical. All the time, the major APIs for routine things are uniform across the entire app.
Now, there are pros and cons to both this approach and the ability of today's.Net to achieve it given the selection of languages available and the support they have. In principle it's a worthy goal, however.
Given this flexibility, in the long run it may be significantly faster to write your program using a selection of languages and combine them via.Net than it would be to use a more "portable" language like C or C++ for everything. You can use the time you save to reengineer your work in a different language on other platforms later if necessary. In the meantime, given the nature of today's commercial development world, your time to market may be so much better with.Net's approach that any other is irrelevant anyway. If you know you're targetting Windows and other platforms may (or may not) come later, better to get the interest in your product up on Windows first rather than let a competitor beat you to it, and leave so few customers that no-one cares by the time your easily portable solution arrives on even one platform.
Java has a similar issue to an extent, but there are so few other mainstream languages available with compilers targetting the JVM that the issue isn't nearly so significant. (Yes, I know there are more than most people think, but.Net appears to have a comparable number of serious languages available already, and Java had several years of head start. It's a much more significant focus in the.Net world.)
Sense of perspective: VS good and bad points
on
Java vs .NET
·
· Score: 1
As someone who's now been an "unofficial evaluator" for VS.Net at two companies, lately including the 2003 revision (or was that VS.Net 2002 SP1?), I have to take issue with some of your points.
Before I do, though, I'll agree with you that in general, VS.Net is a very powerful tool, which has a lot going for it. Most of the freebie tools aren't just unable to compete, they're even in the same league. There are a few notable exceptions, which have been mentioned here, but VS.Net should still have the edge.
I say "should" because I think they've really blown it in a couple of areas, seriously enough to block a lot of development shops from upgradings from VS6. I think if they address these areas in the next release, they'll be right back on top of the pile, but I can see a lot of places holding off on upgrading until their pet "breaking issue" is resolved.
One of those areas is performance. The IDE's responsiveness sucks compared to VS6, in both versions of VS.Net but particularly in 2003. The File|Open... dialog takes half a minute to scan a directory on my system with a few thousand files in it and locks the whole app while it's doing it, FFS. This is simply not acceptable in a modern tool on a multitasking OS, and is almost certainly a result of someone being a bit too clever in "improving" that part of the IDE but forgetting the first rule of Windows message-driven architecture: don't block your UI thread. I can quote several other similarly heinous performance issues if you really want. Generally, it's not bad -- the IDE is very responsive most of the time, and its compilation speed is still pretty good compared to the field. But let's not pretend it has no problems.
They also really blew it by taking out a couple of the most useful features VS6 had. Try searching the MS VS newsgroups for questions asking where the browse toolbar went, and count the number of different threads going back over the past few years. I don't much use the various wizards and resource editors, preferring to write such code by hand for the most part, but I gather from the backlash on the newsgroups that a lot of that changed for little apparent benefit in VS.Net as well.
This makes it particularly unfortunate that, between the 2002 and 2003 releases of VS.Net, they seem to have changed the add-in architecture such that several of the most useful tools available for VS.Net 2002 no longer work. This notably includes the well-known "Call Browser" add-in, much recommended on Microsoft's own newsgroups to fill the gap left by removing the aforementioned browse toolbar.
I've had some contact with guys on the dev team for VS.Net, and they seem to have an excellent attitude and be genuinely enthusiastic about collecting end user feedback and acting on it to improve the product. It seems they're looking at ways to fix the browse toolbar issue in the next release, for example. Let's give credit where it's due, to MS as much as anyone else, but let's keep a sense of perspective as well.
It always amazes me when I hear how sloppy some places are.
Not so long ago, I was elected as an officer for an organisation with a significant bank balance. I was required to attend the bank in person, along with the other new officers whose signatures could access the account, to update the bank records. Some serious ID was required to prove my identity at this point. (I understand this is now a legal requirement under UK anti-laundering rules, and financial institutions are required to confirm ID by one of a few specific means before dealing with you.)
The tragic thing is that the bank didn't require any of the outgoing officers to attend or sign anything, including the minutes of the meeting where my colleagues and I were claiming to be elected! We just took over the whole account with thousands available in it, by typing some words on a piece of paper and calling them minutes.
Now, it happens that the meeting did happen, the minutes were accurate, and we were duly elected, but the bank has no evidence of that beyond our say-so. Sure, they have our ID, but that will only be useful if (a) we didn't provide fakes (which for this much money would be nothing to a pro thief) and (b) we're still within reach by the time they realise we've run off with the cash.
Common attributes are irrelevant in true OO -- after all, with data hiding you never have access to those attributes except through methods anyway.
Indeed. And those who insist on "true" OO even when the accessor/mutator methods confer little or no practical benefit are exactly the reason we have frameworks as bloated as EJB, and the consequent requirements for a layer of code generators to insulate the programmer's sanity from having to work with them directly.
Perish the thought that we should compromise architectural purity for concrete, practical benefits, and thus obviate those code generators entirely...
Code generation can allow a developer to compensate for missing abstractions in the underlying language or architecture.
Thank you; that was the most insightful comment I've seen here all day.
Code generation, like design patterns and such other trendy things, is just a technique you can use with weaker languages or designs to gain some of the power of stronger ones, if you don't have the option to use something more expressive directly. As such, it merits serious consideration as a tool in the toolbox, but if you find yourself writing generator code too often, you're probably using an underpowered and/or overcluttered language to start with.
The type-safe enum idiom in Java, which several people on this thread have mentioned, is a great example. In a language with native support for enumerated constants, such as C, the generator and idiom would be unnecessary; you'd simply write the code. In turn, in a language with stronger support for disjunctive types and pattern matching, a lot of the hackery you see with enums and switch in C is also unnecessary. But some people have to use Java and would find enums useful, and some people have to use C and would find pattern matching useful, and for these people, code generation can be a way to simulate the real thing acceptably well.
Yeah, honestly, these upstart newbies yaccing on about code generation as if it were some sort of new idea. Lex think for a minute and bison other books before we get carried away, shall we?
(And "active code generation" used to be called "high-level languages" and used fairly often by stronger programmers who didn't like cut-and-paste. Maybe that's not buzzwordy enough any more, though.)
Compile-time programming (only available in LISP as far as I'm aware through the eval-when construct)
Also possible with template meta-programming in C++, which is one of the reasons recent expression template libraries and their ilk are getting such good performance.
Yes and no. For normal text, such as you find in comments, of course.
However, the usual "formal" approach to touch-typing, based on a home row and marked keys, isn't nearly so helpful in the context of a punctuation-heavy programming language. Being able to do 85wpm is little use if you're using Perl, where 98% of the characters you type are '/'.:-)
On top of that, developers spend almost no time typing code. The vast majority of their coding time is spent thinking, planning and exploring. And of course, their coding time is a relatively small part of their working time, the majority being spent on activities such as design, debugging and documentation. Touch-typing is great for the latter, of course, so the three of you out there who actually write a sensible amount of useful documentation might find the lessons useful.;-) For everyone else, though, touch-typing is a useful skill, but not so much for development as for other activities related to it.
I hope you have a license on those bricks you build your house with.
I don't need one. They're physical property and can't readily be cloned, and the law is different.
Of course, I do need planning permission to adjust my house significantly, so I can't just build a 12ft wall blocking out all my neighbours' sunlight. Different contexts call for different regulations (or lack thereof). The similarity or otherwise between the context of buying music on a physical medium and the context of buying music electronically is the basic issue here.
2. The legal situation regarding IP is similar in most western countries.
3. There's nothing wrong with having or not having those rights, and paying a different price for each, as long as everyone knows up-front what the deal is. Forcing the seller always to give me the rights isn't necessarily in either of our interests.
(I wasn't giving anything you could sensibly take as legal advice, the weight of five letters as a disclaimer is pretty doubtful, and hell, anyone stupid enough to get legal advice from Slashdot isn't going to be smart enough to sue me anyway...)
Seriously, the only way this becomes a "test case" is if he gets sued, which I really doubt will happen.
I agree with you that it's absurd that he should be sued. Then again, it's also absurd that college kids should wind up losing their life savings for writing a search algorithm. But alas, in the current legal climate in the US, with the big cart^H^H^H^Hindustry bodies intimidating expensive settlements out of easy targets, it takes a lot of guts or a lot of stupidity to do this...
Yes, my point exactly. This is not directly comparable to CDs at present, because there are multiple possible interpretations of what is happening in a legal context, and it's not clear which applies. As I noted, it would be hard to argue that you're not making a copy here, which obviously falls foul of copyright unless some exemption applies.
Slashdot Mirror
Except, of course, that it's the family of the victims who are suing, and whom we might reasonably cut a little slack, not the parents of the shooters.
Basically, yes. You can never convert an integral value (1, 3, whatever) into an enumerator (Red, Green, whatever) without an explicit cast. This includes passing parameters to functions expecting an enumerator, returning enumerators from a function, assigning to a variable of an enumerated type, etc.
That's exactly the right take on this, IMHO. Shortly after the loss of a loved one, it's going to be difficult for anyone to be completely rational and objective. How about cutting them a little slack and dropping the cynicism for once?
You're half-right. An enumerator can be implicitly converted to an integral value, but not the other way around. You have to cast explicitly if you want to turn any other type of value into an enumerator.
Biometrics still have a lot of basic advantages over passwords.
Today:
[Informed cracker dials front desk]
Cracker: Hi, this is John in Support. We're having a problem with your account, could you just confirm the ID and password you use to log in so I can fix it up?
Clueless front desker: Sure, I type johndoe and the password is "reindeer flotilla".
Cracker: Great, thanks. I'll fix your account up right now, and you shouldn't see any difference from usual once it's done.
Next year:
[Informed cracker dials front desk]
Cracker: Hi, this is John in Support. We're having a problem with your account, could you just send me your fingerprint so we can fix it?
Clueless front-desker: Um...
Remember, the two biggest problems with passwords are (a) choosing dumb ones allowing brute-force attacks on a system, and (b) their vulnerability to social engineering attacks. Even simple biometrics would go a long way to fixing those, and thus restricting cracking to those who actually have a clue and not s'kiddies with nothing better to occupy their time.
You don't, by any chance, insist that all passwords consist of a minimum of 27 characters, of which no more than 17 may be alphabetic (but those are case-sensitive) and 40% of the non-alphabetic characters must be punctuation rather than digits, and then make them change to a different hard-to-remember password every five minutes, do you? ;-)
As others have noted, retrofitting some sort of automated testing would be very hard, but can be well worth it in the long run, maybe even this late in a development.
The key ingredients of successful automated test suites I've seen are...
Given the above, all you need is a set of macros and a record of the state that should result, perhaps generated by that macro. (You probably want to record some sort of summary of the state that's likely to reflect as small a change in your state as possible, rather than the full state; often it's the fact that something has changed that is important, not the specifics of what the change was.) Then just replay all the macros and compare the state produced by your current program with the recorded, known-good states, and investigate any discrepancies.
Obviously writing an engine to do these things can be a very significant amount of work. For UI code, particularly if you're using a heavily message-based architecture, it's probably easiest to put the macros in at the message level, IME, which at least gives you a relatively easy way to replay those macros later.
As you can see, we've had our eye on you for some time now, Master of Transhuman. It seems you've been living two lives. In one life, you are a program writer using a respectable development platform. You have a social security number. You pay your taxes. You help your landlady carry out her garbage. The other life is lived on Slashdot, where you go by a hacker alias, advocate the use of a substandard platform, and are guilty of virtually every computer crime Redmond has sponsored a law for. One of these lives has a future, the other does not...
That long, huh?
There are some areas where Visual Studio is behind its competitors. The debugger is not one of them.
I think it's worth bearing in mind the relative productivity of different languages for different tasks.
One of the big selling points of the .Net architecture is that you can realistically write the high level functions of your program in genuinely high level languages, and then use the architecture to communicate with lower-level languages where high performance or refined control is more critical. All the time, the major APIs for routine things are uniform across the entire app.
Now, there are pros and cons to both this approach and the ability of today's .Net to achieve it given the selection of languages available and the support they have. In principle it's a worthy goal, however.
Given this flexibility, in the long run it may be significantly faster to write your program using a selection of languages and combine them via .Net than it would be to use a more "portable" language like C or C++ for everything. You can use the time you save to reengineer your work in a different language on other platforms later if necessary. In the meantime, given the nature of today's commercial development world, your time to market may be so much better with .Net's approach that any other is irrelevant anyway. If you know you're targetting Windows and other platforms may (or may not) come later, better to get the interest in your product up on Windows first rather than let a competitor beat you to it, and leave so few customers that no-one cares by the time your easily portable solution arrives on even one platform.
Java has a similar issue to an extent, but there are so few other mainstream languages available with compilers targetting the JVM that the issue isn't nearly so significant. (Yes, I know there are more than most people think, but .Net appears to have a comparable number of serious languages available already, and Java had several years of head start. It's a much more significant focus in the .Net world.)
As someone who's now been an "unofficial evaluator" for VS.Net at two companies, lately including the 2003 revision (or was that VS.Net 2002 SP1?), I have to take issue with some of your points.
Before I do, though, I'll agree with you that in general, VS.Net is a very powerful tool, which has a lot going for it. Most of the freebie tools aren't just unable to compete, they're even in the same league. There are a few notable exceptions, which have been mentioned here, but VS.Net should still have the edge.
I say "should" because I think they've really blown it in a couple of areas, seriously enough to block a lot of development shops from upgradings from VS6. I think if they address these areas in the next release, they'll be right back on top of the pile, but I can see a lot of places holding off on upgrading until their pet "breaking issue" is resolved.
One of those areas is performance. The IDE's responsiveness sucks compared to VS6, in both versions of VS.Net but particularly in 2003. The File|Open... dialog takes half a minute to scan a directory on my system with a few thousand files in it and locks the whole app while it's doing it, FFS. This is simply not acceptable in a modern tool on a multitasking OS, and is almost certainly a result of someone being a bit too clever in "improving" that part of the IDE but forgetting the first rule of Windows message-driven architecture: don't block your UI thread. I can quote several other similarly heinous performance issues if you really want. Generally, it's not bad -- the IDE is very responsive most of the time, and its compilation speed is still pretty good compared to the field. But let's not pretend it has no problems.
They also really blew it by taking out a couple of the most useful features VS6 had. Try searching the MS VS newsgroups for questions asking where the browse toolbar went, and count the number of different threads going back over the past few years. I don't much use the various wizards and resource editors, preferring to write such code by hand for the most part, but I gather from the backlash on the newsgroups that a lot of that changed for little apparent benefit in VS.Net as well.
This makes it particularly unfortunate that, between the 2002 and 2003 releases of VS.Net, they seem to have changed the add-in architecture such that several of the most useful tools available for VS.Net 2002 no longer work. This notably includes the well-known "Call Browser" add-in, much recommended on Microsoft's own newsgroups to fill the gap left by removing the aforementioned browse toolbar.
I've had some contact with guys on the dev team for VS.Net, and they seem to have an excellent attitude and be genuinely enthusiastic about collecting end user feedback and acting on it to improve the product. It seems they're looking at ways to fix the browse toolbar issue in the next release, for example. Let's give credit where it's due, to MS as much as anyone else, but let's keep a sense of perspective as well.
Not so long ago, I was elected as an officer for an organisation with a significant bank balance. I was required to attend the bank in person, along with the other new officers whose signatures could access the account, to update the bank records. Some serious ID was required to prove my identity at this point. (I understand this is now a legal requirement under UK anti-laundering rules, and financial institutions are required to confirm ID by one of a few specific means before dealing with you.)
The tragic thing is that the bank didn't require any of the outgoing officers to attend or sign anything, including the minutes of the meeting where my colleagues and I were claiming to be elected! We just took over the whole account with thousands available in it, by typing some words on a piece of paper and calling them minutes.
Now, it happens that the meeting did happen, the minutes were accurate, and we were duly elected, but the bank has no evidence of that beyond our say-so. Sure, they have our ID, but that will only be useful if (a) we didn't provide fakes (which for this much money would be nothing to a pro thief) and (b) we're still within reach by the time they realise we've run off with the cash.
I was stunned.
Indeed. And those who insist on "true" OO even when the accessor/mutator methods confer little or no practical benefit are exactly the reason we have frameworks as bloated as EJB, and the consequent requirements for a layer of code generators to insulate the programmer's sanity from having to work with them directly.
Perish the thought that we should compromise architectural purity for concrete, practical benefits, and thus obviate those code generators entirely...
Sure, I'm not claiming C++ has the same raw power that LISP does in this respect, just pointing out that it does provide the features to do it.
Ah, well, I never wanted to be a comedian anyway.
[Brainwave] Maybe I should have written
if I wanted the karma? ;-)
You mean OO isn't a silver bullet, and generics might be useful after all?! Sacrilege!!!
Thank you; that was the most insightful comment I've seen here all day.
Code generation, like design patterns and such other trendy things, is just a technique you can use with weaker languages or designs to gain some of the power of stronger ones, if you don't have the option to use something more expressive directly. As such, it merits serious consideration as a tool in the toolbox, but if you find yourself writing generator code too often, you're probably using an underpowered and/or overcluttered language to start with.
The type-safe enum idiom in Java, which several people on this thread have mentioned, is a great example. In a language with native support for enumerated constants, such as C, the generator and idiom would be unnecessary; you'd simply write the code. In turn, in a language with stronger support for disjunctive types and pattern matching, a lot of the hackery you see with enums and switch in C is also unnecessary. But some people have to use Java and would find enums useful, and some people have to use C and would find pattern matching useful, and for these people, code generation can be a way to simulate the real thing acceptably well.
Yeah, honestly, these upstart newbies yaccing on about code generation as if it were some sort of new idea. Lex think for a minute and bison other books before we get carried away, shall we?
(And "active code generation" used to be called "high-level languages" and used fairly often by stronger programmers who didn't like cut-and-paste. Maybe that's not buzzwordy enough any more, though.)
Also possible with template meta-programming in C++, which is one of the reasons recent expression template libraries and their ilk are getting such good performance.
(say (combine (exclaim Gosh!) (active-clause (subject I) (verb (auxilliary (not can) think)))))
cout << "I can.\n";
System.out.println(":-)");
Yes and no. For normal text, such as you find in comments, of course.
However, the usual "formal" approach to touch-typing, based on a home row and marked keys, isn't nearly so helpful in the context of a punctuation-heavy programming language. Being able to do 85wpm is little use if you're using Perl, where 98% of the characters you type are '/'. :-)
On top of that, developers spend almost no time typing code. The vast majority of their coding time is spent thinking, planning and exploring. And of course, their coding time is a relatively small part of their working time, the majority being spent on activities such as design, debugging and documentation. Touch-typing is great for the latter, of course, so the three of you out there who actually write a sensible amount of useful documentation might find the lessons useful. ;-) For everyone else, though, touch-typing is a useful skill, but not so much for development as for other activities related to it.
I don't need one. They're physical property and can't readily be cloned, and the law is different.
Of course, I do need planning permission to adjust my house significantly, so I can't just build a 12ft wall blocking out all my neighbours' sunlight. Different contexts call for different regulations (or lack thereof). The similarity or otherwise between the context of buying music on a physical medium and the context of buying music electronically is the basic issue here.
1. I'm British, not American.
2. The legal situation regarding IP is similar in most western countries.
3. There's nothing wrong with having or not having those rights, and paying a different price for each, as long as everyone knows up-front what the deal is. Forcing the seller always to give me the rights isn't necessarily in either of our interests.
No, I didn't. :-)
(I wasn't giving anything you could sensibly take as legal advice, the weight of five letters as a disclaimer is pretty doubtful, and hell, anyone stupid enough to get legal advice from Slashdot isn't going to be smart enough to sue me anyway...)
I agree with you that it's absurd that he should be sued. Then again, it's also absurd that college kids should wind up losing their life savings for writing a search algorithm. But alas, in the current legal climate in the US, with the big cart^H^H^H^Hindustry bodies intimidating expensive settlements out of easy targets, it takes a lot of guts or a lot of stupidity to do this...
Yes, my point exactly. This is not directly comparable to CDs at present, because there are multiple possible interpretations of what is happening in a legal context, and it's not clear which applies. As I noted, it would be hard to argue that you're not making a copy here, which obviously falls foul of copyright unless some exemption applies.