I do not understand your comments. Personally I have no VB6 background to speak of, having written only a tiny bit of VB6 and VBA code, but I still find VB.NET more pleasurable than C#. As to the syntax (syntax is superficial and easy to learn) I tend to prefer VB.NET over C#; VB.NET; completely lacks the syntactic sloppiness of VB6/VBA. As to the language features (which, again, are minor), I tend again to side with VB.NET; e.g. VB.NET doesn't use C#'s odd "indexer" syntax, and in VB.NET you can make interface implementations private, which is a pretty cool design aid. All of this is minor detail and a matter of preferecnce; nothing to get a knot in your stomach over. And VB.NET certainly doesn't seem "contrived" to me.
So I really wonder what your problems with VB.NET are. Is it the VB6 compatibility function library? I strongly avoid in my VB.NET code, but again, it's just a library of convenience functions, nothing to feel bad about. Do you hate the lack of type checking? I always enforce it in my code (Option Strict). What else could be wrong with VB.NET, coming from a Java perspective? I just don't see it.
The problem of new versions and compatibility is real, but not unique to VB.
Nobody on this forum ever criticized Sun, or let's say Borland, for introducing new and incompatible versions of their development toolset (previously focueed on C++ when they introduced support for Java. The leap from VB6 or Microsoft C++ version 6 to VB.NET / C# is essentially the same as the leap from C or C++ to Java, except that.NET has much better compatibility with previous tools and techniques. Nobody forces you to use.NET (although Microsoft has plans to discontinue support for VB6); nobody forces you to use the language/platform developer's own development tools (Visual Studio) when developing for them. The suggestion that.NET was just a gratuitious update of Microsoft software to force people to buy the latest version of their tools is just ludicrously uninformed.
The suggestion makes slightly more sense for the 2.0 version of.NET, which is comparable to Java 1.5, introducing generics and similar language extensions. It is arguable that performing such language "upgrades" is a bad idea, but.NET certainly falls within the normal pattern for computer languages: this happens to any popular language, just think of Java, C, C++, FORTRAN, Perl, Python, SQL, HTML, or XSLT. However, compatibility is a major issue, and.NET 2.0 scores rather poorly in this aspect..NET 1 applications do not run on the.NET 2.0 runtime, and they cannot be automatically upgraded; when.NET 1.1 source code (e.g. C# or VB.NET) is fed through a 2.0 compiler, many manual corrections are required. This is very bad; none of the other languages I mentioned is spotless in this area (except perhaps FORTRAN), but they tend to do better.
So overall, it is totally ludicrous to state that "Microsoft keeps coming up with new and incompatible versions of VB", andMicrosoftt certainly doesn't release versions every year (there are over 3 years between.NET 1 and 2), but you do have a point in that compatibility could have been better.
Well, compatibility between Java 1.4 and 1.5 (which is essentially the same step) is a lot better, but I've read that not all Java 1.4 apps run correctly on 1.5.
It works quite well, combined with a procmail filter to sort out my mail for me as it comes in. This has one major drawback: mutt cannot combine mail from different folders, so I keep navigating back and forth between folders, especially when looking for messages that do not have a natural folder to be placed into, and this happens quite a lot. Something like virtual folders (which I've never seen in another client but apparently they exist in some) would be quite useful.
Well said: the belief that those that believe in a creator are wrong is a religious belief, and therefore should not be taught in science class. And indeed, it isn't - not in my experience, at least.
Science is about explaining hy things we see on earth today look the way they do. Natural history, including the results of research on how the fossil record and geology of earth can be explained as gradual developments, is definitely hard science. Creation isn't, and doesn't claim to be: it doesn't at all attempt to explain why things, orlife forms, look the way they do. Frankly I don't see any conflict. There is a conflict if you take the Genesis story literally, or some other creation story, and since these stories are not supported by what we see around us, they have nothing to do with science.
Creation "scientists" are no scientists: they don't try to explain anything. They do try to discredit scientific explanations, but they never ever come up with any support for alternative explanations, and without support, an alternative is not just implausible, it is completely untenable. This is why their ideas have no place in science class. If you think that the notion of the evolution of life is "just an idea", that it isn't the result of painstaking labor to come up with the best explanations of the things we see around us, please read something about fossils, taxonomies of life forms, DNA, etc.
Let me try to go one better: this is not a grammar lesson, it's a lesson in spelling.
Meanwhile, the webserver I administer (although I'm not root) was recently cracked through a PHP application. The crack set up a mini-website used as the recipient of one of those scam e-mails - this case it was telling the recipient to (dis)approve of a certain email address being added to their PayPal account, and of course click the link (apparently to PayPal, in reality to the scam website set up in a crack of our real website).
For reference: the scam in question with Google as
What I already knew: most crackers aren't interested in the machine they crack at all; never trust a PHP application as far as security is concerned; it's pretty easy to discover most cracks but it takes a full daytime job to investigate and report it properly, while the benefits are near-zero, because noone I know or have talked to has time to properly deal with it.
News to me: I didn't realise that the scam sites used to trik people into giving their credit card numbers are themselves set up on cracked hosts;. This is, in fact, the first time a crack that I've witnessed was malicious in intent. (Illegaly copying DVDs can hardly be called malicious.)
I can't agree with you more, but then again, you have to realise that Java and C# are essentially attempts to sell basic programming concepts to C programmers. They had to dumb the languages down so as not to alienate the intended audience too much. C# has a nice roadmap towards more functional programming concepts. The whole idea is to get more people to use saner programming techniques without them realizing it.
Sorry, but this is bullshit. You, as pretty much everyone else who I've seen spouting on this issue
haven't even considered what it means for a format to be open and why it's supposed to solve the interoperability problem.
An open document format is a format described by a freely avaailable published standard. If your software conforms to such an open standard, it guarantees that the documents it reads and writes have the form and meaning described in that standard (as far as form and meaning are described in that standard).
This helps with interoperability because you can now define your format in terms of a particular version of the standard, instead of having to rely on a particular version of a particular set of software tools. So in 2145 when a document is needed the courts will be able to use it with whatever software also conforms to the standard, rather than having to dig up an old computer and a couple of contemporary versions of OpenOffice, hoping to somehow find one that appears to be compatible with the format of the document in question, and pray.
Microsoft's Office formats *are* open: http://www.microsoft.com/office/xml/default.mspx Open Office's are *not*: they do not have a published specification, although work is underway to address that.
Of course open standards only work to the extent that they unambiguously describe all the features needed by the projects that use them, and to the extent that users only rely on features described by the standards. For example, Word documents can contain arbitrary macros and ActiveX controls, which aren't covered by the standard, so don't use them if you need to rely on the standard for interoperability, or write your own standard that does cover them, and then certify the Word you use to conform to it. (And it's really really hard to describe anything of interest unambiguously in a standard.)
Of course OpenOffice has a different advantage: the software itself is free, so it's generally easier to obtain when needed to open a particular document. But that has nothing to do with whether the document format it uses is open. And it won't make much of a difference in 2145.
I know others have responded to this at a time when people were still reading the comments, but I just can't resist: the clergy were extremely important for the development of thought in Europe in the Middle Ages. Not only did the monasterial orders form the first (that I know of) true multinational enterprises - once a monk you could be educated and then sent out to serve anywhere in the area the order was active, which for many was all over Europe, so this was a great help to the spreading of knowledge and education - they also provided a true alternative society, an escape from the very hierarchical and belligerent feudal pecking order of everyday life, with its focus on short-term results and consequences. A person could either submit to the harsh realities of the layman's world, or choose the clergyman's way out, into a very different way of life, possibly just as hard, but focused much more on the longer term. This (fairly absolute) independence of the clergy from feodal rule came at a price, of course, the acceptance of the total rule of God, but I believe it paved the way for the later, secular, colleges that shaped the first univerities. Many early scientific thinkers, such as Thomas of Aquino and William of Ockham, were clergymen.
Joel Spolsky's article first bings up some findings from hard data:
- programming seems to take almost arbitrarily long; there appears to be next to no limit on maximum time and deviation (except hard deadlines)
- there is no correlation at all between the time used and the quality of the result
The question is whether quality correlates with other variables than time, more specifically, with the programmer.
So the next step should be: when looking at the scores of individual programmers, do we see consistency? Is there such a thing as a "good" programmer, who scores consistently better quality than the average programmer?
Joel's report becomes a little ambiguous at this point. He selects "the top 25% programmers" without saying how. I'm confident he selected the programmers who took the first 25% of overall (averaged) quality scores. I do not believe he selected the first 25% of results for every exercise, but the wording doesn't completely exclude it.
He reports that, collectively, these top 25% of programmers take almost exactly as much time as the rest (both in maximum and in deviation).
He then leaves the data and starts about the difference between good and average programmers. This is a total non sequitur. Nothing he says about that difference is supported by his analysis.
It might seem at first glance that the analysis supports the notion that there is such a thing as "the good programmer". But it doesn't. Joel doesn't give us any information on whether some programmers perform better than others. He looks at the ones that came out in the top 25% and *calls* them the "best programmers". For all we know, the quality scores were completely random and the programmers that came out on top just got lucky this time. To see if quality of code is correlated with the programmer writing it, we should see if there is any consistency in the difference between individual programmers' scores across exercises. Joel didn't do this. He committed the classical logical error of assuming what he wanted to demonstrate, namely, that there is a difference between "good" and "average" programmers.
For now, let's gloss over this fatal weakness and go along with Joel's (plausible) hypothesis that there is such a thing as a difference between "good" and "average" programmers. We now come to the strong point of the article. Joel was, of course, hoping to find that the programmers who produced (on average) the best quality code were also the faster ones. But they aren't: they are just as slow as the average programmer.
It's to Joel's credit that he doesn't hesitate to report these findings, since in my eyes they are fatal to the hypothesis he started out with.
What these figures prove is that the good programmers (those with good results on average) are just as slow as the average ones. The difference in productivity solely consisted of the fact that the top 25% got better results - but that is not exactly surprising, since it is how they were selected.
Amazingly, Joel draws the opposite conclusion: these same figures are supposed to demonstrate a 5-10 times speed difference between programmers! But that is only when measuring on individual exercises. It is completely unwarranted to draw any conclusions on the speed difference across exercises.
OK, so we don't really see any difference in productivity. "But wait, there is more! (...) No matter how long (mediocre programmers) work, they never produce something as good as what the great programmers can produce."
Um, where exactly did we see this? Did the data provide any evidence that some programmers never find good solutions? Nope. Do some programmers arrive at good solutions all the time? No idea. if they did, I would think they would also work faster than the average programmer, and they don't. SO again, Joel is pulling his statement out of thin air, and the relationship with the data is no more than suggestion.
To many eyes, all bugs are shallow, as Eric Raymind wrote. But it works both ways. Put in front of a one million line program written by someone else, all programmers are idiots: it will take a while to understand the thing well enough to know where and how to make sensible changes. This is what stuff like strong typing was made for. Engineering, rather than the look-mommy-i-can-type-and-it-does-things-for-me 2000 line Perl script you and I spit out every once in a while. The continued use of C outside its original niche, and the inevitable stream of hioghest-urgency bugs that this generates, is clear proof of the immaturity of computer programming as an engineering discipline.
diagrams for discrete process modeling
on
Graphics in Science
·
· Score: 3, Interesting
As a programmer and sometimes teaching assistant I've been doing a lot of stuff with techniques to represent the structure of information (ER models, UML class diagrams, RDF, etc.) and of discrete processes (state machines, flow diagrams, Petri nets, UML activity diagrams, UML message sequence charts, etc.)
Considering the popularity of such techniques I find it odd how little material I have encountered on their actual useability, compared to other forms of representation. There still appear to be hordes of professionals in the software industry who routinely dismiss diagram techniques as being useless, or worse, a tell-tale sign of a weak mind (as Dijkstra did), without feeling the slightest need to substantiate such sentiment with evidence of any kind. At the same time, none of the proponents of diagram techniques I have seen (speaking or in writing) make any serious useability arguments in favour. Clearly it's easy to draw up small examples on which a particular diagram technique does well, and other examples to discredit the same technique. But that is the full extent to which the matter seems to be dealt with, even among professional software design specialists, such as the designers of the UML.
So what I have been reading, mostly between the lines, is that formulas are "too hard" while diagrams are "too easy". Well, on the whole there may be a grain of truth in this thought, but I'd like to see more details. Are there any serious studies on the useability for diagrams (vs. that of tables, or formulas, or other types of visualizations) for conveying information? Or is this whole subject really as trivial as everybody appears to believe?
OK. I'll reply to this in the best/. traditions, i.e. not having read the article, and under severe influence of a(n unfortunately legal) mind-altering substance that, at this stage, barely allows me to type.
What I want to say is that Robert Pirsig, whose book, "Zen and the art of Motorcycle Maintenance", I read over 20 years ago, is right: there *is* such a thing as *quality*. I have been watching Buffy re-reruns, which somehow started at ungodly hours when I should have been asleep, but what kept me glued to the screen was this exact feature: quality. Granted, some of the episodes are lousy, but sometimes there are jewels of sheer beauty - not just in the way in which characters are elevated to be beautiful, but also in the integrated whole of an episode. This never struck me harder than in the episode in which everybody had magically lost the faculty of speech, and an hour of television was spent without a word being uttered. I watched in fascination, my mind divided between adulation - I was enjoying what I saw - and meta-adulation, coming from, if you will, the engineer in me: the feeling: wow, these guys purposely set out to do this, and they managed to make it work!
Joss Whedon is quality. Joss Whedon means: no matter how many cliches, there will be something that transcends them, that will hold your interest, that will attempt to play around with conventions and see to what extent they can be stretched and still work. TV has seen enough formulas, it needs challenges. Whedon seems to be one of the persons who are willing to take these challenges every now and then.
I think you have a serious misunderstanding about the medium.
Like Usenet, this is a discussion forum, not a service call center. If you want straight answers to straight questions, *pay* for that right. And as someone else writes, for god's sake don't turn to a geek forum. If you want discussion on what the problem really is and how to best approach it, that;s when you go too Slashdot or some such place, but don't expect to get a direct answer to your question. In fact, I go to restaurants with a similar attitude. Admittedly, when I go there and say "no pork" I would be annoyed by a waiter insisting that "the chef's pork is the best"" but I wouldn't in the least bit mind to explain the underlying reasons, so the house can serve my needs better. If you want to eat out and not be surprised, go to McDonald's. Thanks.
Tests cannot be generic. It is impossible to test all possible code paths, there are infinitely many.Your tests are only going to cover a couple of use cases. So tests do not fully document functionality.
Open source development only works if you can release early and often; you've got to have something useable along the way. Creating a new game is fairly easy but it's really hard to get a user base, and hence, a developer base, for it. Freeciv started out as an exercise in multiplayer mode design, not in game rule design, so creating a new game wasn't an objective initially.
It is still a major objective for Freeciv to find new games within the existing game, and new extensions of its configurability to allow these games. Many such games can already be defined, for example, you can already create a configuration that is quite similar to board games such as chess or stratego.
In "hard" mode, the AI knows the complete map, in fact the complete game state, and it gets a science bonus (it can research at 100% if it wants to). Also, it doesn't get interrupted by other players' actions, but this is a mixed blessing. It doesn't use any other cheats as far as I know.
What is more, at one point the USA and Saddam were (politically) best friends, and Bush and Bin Laden stem from circles with close business relationships. It's easy to make things appear black-and-white on TV (even on color TV) but the real situation is a little more complicated.
What these people have in common is that they are/were fueled by oil wealth.
I haven't read the book, and I don't intend to, but I do think the review gives a rather good assessment of what the shift to PHP 5 means in practice.
I am personally of the conviction that OO is among those things that are absolute necessities to keep the work of mediocre (sloppy) programmers like myself moderately sane and structured, as soon as the number of lines exceeds throwaway level, say, 10,000 lines or more. I can't read my own code, let alone that of somebody else, if it's more than 10,000 lines and doesn't have a good class diagram as its basis, unless some other methodology was used, and those other methodologies are more problem specific than OO.
Now I've seen (and luckily enough, managed to largely stay out of participating in) a project that was done in PHP4. Honest attempts were made (I swear) to separate user interface from business logic and to implement the latter in terms of an OO class design, but PHP wouldn't even let us *pass references as function arguments* without complaining. Which meant the OO support that was there was little more than shallow imitation. Which basically meant we couldn't implement the class design because the language wouldn't let us.
As you may have guessed by now I'm also a fervent advocate of strong, static typing so I wouldn't trust myself with PHP 5 anyway, but it's good to know that they have at least managed to pass the hurdle of knowing what a reference is. It is (truly!) remarkable to see the power of open source in PHP, which has grown from a dirty hack of a Perl script to improve upon the even worse hack of Apache SSI, into a full-blown programming language, and I'd regard it as past its adolescence. The reviewer rightly points out XML support as a particular area in which previous versions of PHP lacked maturity. So it's getting there, but if you ask me: where exactly, I'll reply: where Java, NET and possibly some other languages are today.
Rule the earth today!
on
Sim Epidemic
·
· Score: 1
Rather, it means that when/.'ers rule the earth, they are usually constructing a simulation.
To me at least the whole project reminds me of another, which has free software to construct even better simulations (multiple viruses at once) - and it allows you to rule the earth at the same time!
I can't agree more. The *only*, I repeat: *only* reason Google and Altavista work is that you know what you're asking for, namely, for pages that actually contained the word(s) or phrase you are specifying. Lately I've noticed that Google is starting to return pages that do *not* literally contain the terms I'm specifying.
Let me put it to you straight dear Google: this is *fucking retarded* and I'm going to seriously search for a competitor that doesn't do this unless you cease to do this *real soon now*. The nice age-old horse-beaten-to-death IR concepts about search engines outsmarting their users do not work, period.
Perhaps you really need an *atomic* IsNot in some cases (think of concurrency) and perhaps the IsNot operator is defined to provide that (I haven't checked the patent). I don't think the sequence
Not (a Is b)
absolutely guarantees that by the time the Not has been executed, a and b still have the same value thet had when they were evaluated.
On a related note: today I received a couple of.zip attachments that each contained a file with a name of the form foo.html\ \ \ [a couple more] \ \.com
(This is what I saw on my shell prompt; they were newlines really.) Executables of course, and no doubt viruses. But this trick was new to me.
No doubt that all man-made artifacts have an intelligent designer, but at the same time, it would be totally impossible for an intelligent human being to design any of the things you mention from scratch, without a lengthy history of very similar designs and implementations preceding it. The chair I sit in has a *thousand* intelligent designers! My computer has even more. Computers and chairs have evolved through a tril-and-error process; if they didn't evolve, they would not exist today.
This goes to show that "pure" design, a specification of a chair or a computer, without a trial-and-error process to determine what works well and what does well among users, is only a small aspect of the development process of chairs, computers, or anything else made by man.
So even for artefacts for which intelligent design is clearly an important and possibly necessary factor in their creation, the development process of such artefacts in the long term is evolution. (Not: looks like evolution. It is the same process. The difference is that it doesn't operate on living beings, it doesn't work with genes.)
While I agree with you that the chances of life forming out of primordial soup seem pretty slim, I think you are totally mistaken about the relationship between intelligent design and evolutionary processes.
Slashdot Mirror
I do not understand your comments. Personally I have no VB6 background to speak of, having written only a tiny bit of VB6 and VBA code, but I still find VB.NET more pleasurable than C#. As to the syntax (syntax is superficial and easy to learn) I tend to prefer VB.NET over C#; VB.NET; completely lacks the syntactic sloppiness of VB6/VBA. As to the language features (which, again, are minor), I tend again to side with VB.NET; e.g. VB.NET doesn't use C#'s odd "indexer" syntax, and in VB.NET you can make interface implementations private, which is a pretty cool design aid. All of this is minor detail and a matter of preferecnce; nothing to get a knot in your stomach over. And VB.NET certainly doesn't seem "contrived" to me.
So I really wonder what your problems with VB.NET are. Is it the VB6 compatibility function library? I strongly avoid in my VB.NET code, but again, it's just a library of convenience functions, nothing to feel bad about. Do you hate the lack of type checking? I always enforce it in my code (Option Strict). What else could be wrong with VB.NET, coming from a Java perspective? I just don't see it.
The problem of new versions and compatibility is real, but not unique to VB.
.NET has much better compatibility with previous tools and techniques. Nobody forces you to use .NET (although Microsoft has plans to discontinue support for VB6); nobody forces you to use the language/platform developer's own development tools (Visual Studio) when developing for them. The suggestion that .NET was just a gratuitious update of Microsoft software to force people to buy the latest version of their tools is just ludicrously uninformed.
.NET, which is comparable to Java 1.5, introducing generics and similar language extensions. It is arguable that performing such language "upgrades" is a bad idea, but .NET certainly falls within the normal pattern for computer languages: this happens to any popular language, just think of Java, C, C++, FORTRAN, Perl, Python, SQL, HTML, or XSLT. However, compatibility is a major issue, and .NET 2.0 scores rather poorly in this aspect. .NET 1 applications do not run on the .NET 2.0 runtime, and they cannot be automatically upgraded; when .NET 1.1 source code (e.g. C# or VB.NET) is fed through a 2.0 compiler, many manual corrections are required. This is very bad; none of the other languages I mentioned is spotless in this area (except perhaps FORTRAN), but they tend to do better.
.NET 1 and 2), but you do have a point in that compatibility could have been better.
Nobody on this forum ever criticized Sun, or let's say Borland, for introducing new and incompatible versions of their development toolset (previously focueed on C++ when they introduced support for Java. The leap from VB6 or Microsoft C++ version 6 to VB.NET / C# is essentially the same as the leap from C or C++ to Java, except that
The suggestion makes slightly more sense for the 2.0 version of
So overall, it is totally ludicrous to state that "Microsoft keeps coming up with new and incompatible versions of VB", andMicrosoftt certainly doesn't release versions every year (there are over 3 years between
Worlf of Warcraft evolved from similar, more primitive computer games.
Think about it.
Well, compatibility between Java 1.4 and 1.5 (which is essentially the same step) is a lot better, but I've read that not all Java 1.4 apps run correctly on 1.5.
It works quite well, combined with a procmail filter to sort out my mail for me as it comes in. This has one major drawback: mutt cannot combine mail from different folders,
so I keep navigating back and forth between folders, especially when looking for messages that do not have a natural folder to be placed into, and this happens quite a lot. Something like virtual folders (which I've never seen in another client but apparently they exist in some) would be quite useful.
Well said: the belief that those that believe in a creator are wrong is a religious belief, and therefore should not be taught in science class. And indeed, it isn't - not in my experience, at least.
Science is about explaining hy things we see on earth today look the way they do. Natural history, including the results of research on how the fossil record and geology of earth can be explained as gradual developments, is definitely hard science. Creation isn't, and doesn't claim to be: it doesn't at all attempt to explain why things, orlife forms, look the way they do. Frankly I don't see any conflict. There is a conflict if you take the Genesis story literally, or some other creation story, and since these stories are not supported by what we see around us, they have nothing to do with science.
Creation "scientists" are no scientists: they don't try to explain anything. They do try to discredit scientific explanations, but they never ever come up with any support for alternative explanations, and without support, an alternative is not just implausible, it is completely untenable. This is why their ideas have no place in science class. If you think that the notion of the evolution of life is "just an idea", that it isn't the result of painstaking labor to come up with the best explanations of the things we see around us, please read something about fossils, taxonomies of life forms, DNA, etc.
Let me try to go one better: this is not a grammar lesson, it's a lesson in spelling.
q =%22New+email+address+added+to+your+PayPal+account !%22
Meanwhile, the webserver I administer (although I'm not root) was recently cracked through a PHP application.
The crack set up a mini-website used as the recipient of one of those scam e-mails - this case it was telling the recipient to (dis)approve of a certain email address being added to their PayPal account, and of course click the link (apparently to PayPal, in reality to the scam website set up in a crack of our real website).
For reference: the scam in question with Google as
http://www.google.com/search?client=opera&rls=en&
What I already knew: most crackers aren't interested in the machine they crack at all; never trust a PHP application as far as security is concerned; it's pretty easy to discover most cracks but it takes a full daytime job to investigate and report it properly, while the benefits are near-zero, because noone I know or have talked to has time to properly deal with it.
News to me: I didn't realise that the scam sites used to trik people into giving their credit card numbers are
themselves set up on cracked hosts;. This is, in fact, the first time a crack that I've witnessed was malicious in intent. (Illegaly copying DVDs can hardly be called malicious.)
I can't agree with you more, but then again, you have to realise that Java and C# are essentially attempts to sell basic programming concepts to C programmers. They had to dumb the languages down so as not to alienate the intended audience too much. C# has a nice roadmap towards more functional programming concepts. The whole idea is to get more people to use saner programming techniques without them realizing it.
...
Just my 2 Eurocents, as always
Sorry, but this is bullshit. You, as pretty much everyone else who I've seen spouting on this issue
haven't even considered what it means for a format to be open and why it's supposed to solve the interoperability problem.
An open document format is a format described by a freely avaailable published standard. If your software conforms to such an open standard, it guarantees that the documents it reads and writes have the form and meaning described in that standard (as far as form and meaning are described in that standard).
This helps with interoperability because you can now define your format in terms of a particular version of the standard, instead of having to rely on a particular version of a particular set of software tools. So in 2145 when a document is needed the courts will be able to use it with whatever software also conforms to the standard, rather than having to dig up an old computer and a couple of contemporary versions of OpenOffice, hoping to somehow find one that appears to be compatible with the format of the document in question, and pray.
Microsoft's Office formats *are* open: http://www.microsoft.com/office/xml/default.mspx
Open Office's are *not*: they do not have a published specification, although work is underway to address that.
Of course open standards only work to the extent that they unambiguously describe all the features needed by the projects that use them, and to the extent that users only rely on features described by the standards. For example, Word documents can contain arbitrary macros and ActiveX controls, which aren't covered by the standard, so don't use them if you need to rely on the standard for interoperability, or write your own standard that does cover them, and then certify the Word you use to conform to it. (And it's really really hard to describe anything of interest unambiguously in a standard.)
Of course OpenOffice has a different advantage: the software itself is free, so it's generally easier to obtain when needed to open a particular document. But that has nothing to do with whether the document format it uses is open.
And it won't make much of a difference in 2145.
I know others have responded to this at a time when people were still reading the comments, but I just can't resist: the clergy were extremely important for the development of thought in Europe in the Middle Ages. Not only did the monasterial orders form the first (that I know of) true multinational enterprises - once a monk you could be educated and then sent out to serve anywhere in the area the order was active, which for many was all over Europe, so this was a great help to the spreading of knowledge and education - they also provided a true alternative society, an escape from the very hierarchical and belligerent feudal pecking order of everyday life, with its focus on short-term results and consequences. A person could either submit to the harsh realities of the layman's world, or choose the clergyman's way out, into a very different way of life, possibly just as hard, but focused much more on the longer term. This (fairly absolute) independence of the clergy from feodal rule came at a price, of course, the acceptance of the total rule of God, but I believe it paved the way for the later, secular, colleges that shaped the first univerities. Many early scientific thinkers, such as Thomas of Aquino and William of Ockham, were clergymen.
Joel Spolsky's article first bings up some findings from hard data:
- programming seems to take almost arbitrarily long; there appears to be next to no limit on maximum time and deviation (except hard deadlines)
- there is no correlation at all between the time used and the quality of the result
The question is whether quality correlates with other variables than time, more specifically, with the programmer.
So the next step should be: when looking at the scores of individual programmers, do we see consistency? Is there such a thing as a "good" programmer, who scores consistently better quality than the average programmer?
Joel's report becomes a little ambiguous at this point. He selects "the top 25% programmers" without saying how. I'm confident he selected the programmers who took the first 25% of overall (averaged) quality scores. I do not believe he selected the first 25% of results for every exercise, but the wording doesn't completely exclude it.
He reports that, collectively, these top 25% of programmers take almost exactly as much time as the rest (both in maximum and in deviation).
He then leaves the data and starts about the difference between good and average programmers. This is a total non sequitur. Nothing he says about that difference is supported by his analysis.
It might seem at first glance that the analysis supports the notion that there is such a thing as "the good programmer". But it doesn't. Joel doesn't give us any information on whether some programmers perform better than others. He looks at the ones that came out in the top 25% and *calls* them the "best programmers". For all we know, the quality scores were completely random and the programmers that came out on top just got lucky this time. To see if quality of code is correlated with the programmer writing it, we should see if there is any consistency in the difference between individual programmers' scores across exercises. Joel didn't do this. He committed the classical logical error of assuming what he wanted to demonstrate, namely, that there is a difference between "good" and "average" programmers.
For now, let's gloss over this fatal weakness and go along with Joel's (plausible) hypothesis that there is such a thing as a difference between "good" and "average" programmers. We now come to the strong point of the article. Joel was, of course, hoping to find that the programmers who produced (on average) the best quality code were also the faster ones. But they aren't: they are just as slow as the average programmer.
It's to Joel's credit that he doesn't hesitate to report these findings, since in my eyes they are fatal to the hypothesis he started out with.
What these figures prove is that the good programmers (those with good results on average) are just as slow as the average ones. The difference in productivity solely consisted of the fact that the top 25% got better results - but that is not exactly surprising, since it is how they were selected.
Amazingly, Joel draws the opposite conclusion: these same figures are supposed to demonstrate a 5-10 times speed difference between programmers! But that is only when measuring on individual exercises. It is completely unwarranted to draw any conclusions on the speed difference across exercises.
OK, so we don't really see any difference in productivity. "But wait, there is more! (...) No matter how long (mediocre programmers) work, they never produce something as good as what the great programmers can produce."
Um, where exactly did we see this? Did the data provide any evidence that some programmers never find good solutions? Nope. Do some programmers arrive at good solutions all the time? No idea. if they did, I would think they would also work faster than the average programmer, and they don't. SO again, Joel is pulling his statement out of thin air, and the relationship with the data is no more than suggestion.
On the whole, an interesting, but flawed article.
"So many programmers are idiots."
To many eyes, all bugs are shallow, as Eric Raymind wrote. But it works both ways. Put in front of a one million line program written by someone else, all programmers are idiots: it will take a while to understand the thing well enough to know where and how to make sensible changes. This is what stuff like strong typing was made for. Engineering, rather than the look-mommy-i-can-type-and-it-does-things-for-me 2000 line Perl script you and I spit out every once in a while. The continued use of C outside its original niche, and the inevitable stream of hioghest-urgency bugs that this generates, is clear proof of the immaturity of computer programming as an engineering discipline.
As a programmer and sometimes teaching assistant I've been doing a lot of stuff with techniques to represent the structure of information (ER models, UML class diagrams, RDF, etc.) and of discrete processes (state machines, flow diagrams, Petri nets, UML activity diagrams, UML message sequence charts, etc.)
Considering the popularity of such techniques I find it odd how little material I have encountered on their actual useability, compared to other forms of representation. There still appear to be hordes of professionals in the software industry who routinely dismiss diagram techniques as being useless, or worse, a tell-tale sign of a weak mind (as Dijkstra did), without feeling the slightest need to substantiate such sentiment with evidence of any kind. At the same time, none of the proponents of diagram techniques I have seen (speaking or in writing) make any serious useability arguments in favour. Clearly it's easy to draw up small examples on which a particular diagram technique does well, and other examples to discredit the same technique. But that is the full extent to which the matter seems to be dealt with, even among professional software design specialists, such as the designers of the UML.
So what I have been reading, mostly between the lines, is that formulas are "too hard" while diagrams are "too easy". Well, on the whole there may be a grain of truth in this thought, but I'd like to see more details. Are there any serious studies on the useability for diagrams (vs. that of tables, or formulas, or other types of visualizations) for conveying information? Or is this whole subject really as trivial as everybody appears to believe?
OK. I'll reply to this in the best /. traditions, i.e. not having read the article, and under severe influence of a(n unfortunately legal) mind-altering substance that, at this stage, barely allows me to type.
What I want to say is that Robert Pirsig, whose book, "Zen and the art of Motorcycle Maintenance", I read over 20 years ago, is right: there *is* such a thing as *quality*. I have been watching Buffy re-reruns, which somehow started at ungodly hours when I should have been asleep, but what kept me glued to the screen was this exact feature: quality. Granted, some of the episodes are lousy, but sometimes there are jewels of sheer beauty - not just in the way in which characters are elevated to be beautiful, but also in the integrated whole of an episode. This never struck me harder than in the episode in which everybody had magically lost the faculty of speech, and an hour of television was spent without a word being uttered. I watched in fascination, my mind divided between adulation - I was enjoying what I saw - and meta-adulation, coming from, if you will, the engineer in me: the feeling: wow, these guys purposely set out to do this, and they managed to make it work!
Joss Whedon is quality. Joss Whedon means: no matter how many cliches, there will be something that transcends them, that will hold your interest, that will attempt to play around with conventions and see to what extent they can be stretched and still work. TV has seen enough formulas, it needs challenges. Whedon seems to be one of the persons who are willing to take these challenges every now and then.
I think you have a serious misunderstanding about the medium.
Like Usenet, this is a discussion forum, not a service call center. If you want straight answers to straight questions, *pay* for that right. And as someone else writes, for god's sake don't turn to a geek forum. If you want discussion on what the problem really is and how to best approach it, that;s when you go too Slashdot or some such place, but don't expect to get a direct answer to your question.
In fact, I go to restaurants with a similar attitude. Admittedly, when I go there and say "no pork" I would be annoyed by a waiter insisting that "the chef's pork is the best"" but I wouldn't in the least bit mind to explain the underlying reasons, so the house can serve my needs better. If you want to eat out and not be surprised, go to McDonald's. Thanks.
Tests cannot be generic. It is impossible to test all possible code paths, there are infinitely many.Your tests are only going to cover a couple of use cases. So tests do not fully document functionality.
Open source development only works if you can release early and often; you've got to have something useable along the way. Creating a new game is fairly easy but it's really hard to get a user base, and hence, a developer base, for it. Freeciv started out as an exercise in multiplayer mode design, not in game rule design, so creating a new game wasn't an objective initially.
It is still a major objective for Freeciv to find new games within the existing game, and new extensions of its configurability to allow these games. Many such games can already be defined, for example, you can already create a configuration that is quite similar to board games such as chess or stratego.
In "hard" mode, the AI knows the complete map, in fact the complete game state, and it gets a science bonus (it can research at 100% if it wants to). Also, it doesn't get interrupted by other players' actions, but this is a mixed blessing. It doesn't use any other cheats as far as I know.
What is more, at one point the USA and Saddam were (politically) best friends, and Bush and Bin Laden stem from circles with close business relationships. It's easy to make things appear black-and-white on TV (even on color TV) but the real situation is a little more complicated.
What these people have in common is that they are/were fueled by oil wealth.
I haven't read the book, and I don't intend to, but I do think the review gives a rather good assessment of what the shift to PHP 5 means in practice.
I am personally of the conviction that OO is among those things that are absolute necessities to keep the work of mediocre (sloppy) programmers like myself moderately sane and structured, as soon as the number of lines exceeds throwaway level, say, 10,000 lines or more. I can't read my own code, let alone that of somebody else, if it's more than 10,000 lines and doesn't have a good class diagram as its basis, unless some other methodology was used, and those other methodologies are more problem specific than OO.
Now I've seen (and luckily enough, managed to largely stay out of participating in) a project that was done in PHP4. Honest attempts were made (I swear) to separate user interface from business logic and to implement the latter in terms of an OO class design, but PHP wouldn't even let us *pass references as function arguments* without complaining. Which meant the OO support that was there was little more than shallow imitation. Which basically meant we couldn't implement the class design because the language wouldn't let us.
As you may have guessed by now I'm also a fervent advocate of strong, static typing so I wouldn't trust myself with PHP 5 anyway, but it's good to know that they have at least managed to pass the hurdle of knowing what a reference is. It is (truly!) remarkable to see the power of open source in PHP, which has grown from a dirty hack of a Perl script to improve upon the even worse hack of Apache SSI, into a full-blown programming language, and I'd regard it as past its adolescence. The reviewer rightly points out XML support as a particular area in which previous versions of PHP lacked maturity. So it's getting there, but if you ask me: where exactly, I'll reply: where Java, NET and possibly some other languages are today.
Rather, it means that when /.'ers rule the earth, they are usually constructing a simulation.
3 74250
r s=12&minturns=200
To me at least the whole project reminds me of another, which has free software to construct even better simulations (multiple viruses at once) - and it allows you to rule the earth at the same time!
See
http://pubserver.freeciv.org/viewgame.phtml?game=
for an example, and
http://pubserver.freeciv.org/query.phtml?minplaye
for a couple more.
I can't agree more. The *only*, I repeat: *only* reason Google and Altavista work is that you know what you're asking for, namely, for pages that actually contained the word(s) or phrase you are specifying. Lately I've noticed that Google is starting to return pages that do *not* literally contain the terms I'm specifying.
Let me put it to you straight dear Google: this is *fucking retarded* and I'm going to seriously search for a competitor that doesn't do this unless you cease to do this *real soon now*. The nice age-old horse-beaten-to-death IR concepts about search engines outsmarting their users do not work, period.
Thank you.
Perhaps you really need an *atomic* IsNot in some cases (think of concurrency) and perhaps the IsNot operator is defined to provide that (I haven't checked the patent). I don't think the sequence
Not (a Is b)
absolutely guarantees that by the time the Not has been executed, a and b still have the same value thet had when they were evaluated.
Just a guess.
On a related note: today I received a couple of .zip attachments that each contained a file with a name of the form foo.html\ \ \ [a couple more] \ \.com
(This is what I saw on my shell prompt; they were newlines really.) Executables of course, and no doubt viruses. But this trick was new to me.
No doubt that all man-made artifacts have an intelligent designer, but at the same time, it would be totally impossible for an intelligent human being to design any of the things you mention from scratch, without a lengthy history of very similar designs and implementations preceding it. The chair
I sit in has a *thousand* intelligent designers! My computer has even more.
Computers and chairs have evolved through a tril-and-error process; if they didn't evolve, they would not exist today.
This goes to show that "pure" design, a specification of a chair or a computer, without a trial-and-error process to determine what works well and what does well among users, is only a small aspect of the development process of chairs, computers, or anything else made by man.
So even for artefacts for which intelligent design is clearly an important and possibly necessary factor in their creation, the development process of such artefacts in the long term is evolution. (Not: looks like evolution. It is the same process. The difference is that it doesn't operate on living beings, it doesn't work with genes.)
While I agree with you that the chances of life forming out of primordial soup seem pretty slim, I think you are totally mistaken about the relationship between intelligent design and evolutionary processes.