Um, no. You have Object.toString() which is a method, not an operator.
Perhaps my terminology isn't the norm in the Java world, but nonetheless, what you have is exactly the same as a conversion operator in other languages. It is a means of implicitly converting between types. Except that in Java, you can only set that up for conversion to a String implicitly. (Don't even get me started on why all classes should have to provide this method in the first place, or on the common root class flamefest.)
It sounds like you're talking about why operator overloading is necessary for C. For one, "user-defined types" don't exist in Java.
Really? What's a class, then?
Second, I don't agree with what you're saying. What about Lisp? Do you think that Lisp is a poor language because you don't add two numbers by saying 1 + 2? Lisp breaks your "accepted standards for how we write... addition".
Lisp has an accepted standard of its own: (+ 1 2) is the sum of the numbers 1 and 2. The point is not a universal notation, but a consistent notation within the language, which allows you to write a generic method once that can work with any suitable type without further modification.
Your example is particularly ironic because Lisp's S-expressions are a prime example of exactly the sort of uniform syntax I'm advocating here.
Re:AAAAAAAAArgh -- missing the point sooo badly
on
Java Gets Templates
·
· Score: 2
With respect, I think you miss the point as well. The fact that Java treats primitive types differently from those derived from Object is already a serious thorn in the side of many a programmer. This sort of generic feature could provide a systematic, uniform way of dealing with such types, banishing the need to use bastardisations like Integer to a much smaller range of applications. This, IMHO, is a Good Thing.
You're quite right, of course, that it doesn't make sense to try to add an apple and the colour purple. What you're ignoring is that you simply wouldn't provide an addition operator taking a Bicycle and an Orange, and thus trying to do add them with a generic function could and should result in a compile-time error, or at least a run-time error if you're relying on late binding. There is no problem here; at worst it's the same as what you've got if you do the same thing in non-generic code now.
Since no-one has yet pointed it out that I can see, it should be noted that what we're talking about here is parameterised types, and to a limited extent, parameterised methods. This is still quite some way from what you can do with serious generics in other languages.
There is an obvious comparison with C++ templates here, and although those are not the best generics around themselves, they do have a few very useful tricks up their sleeves. In Java, you can now do parameterised containers, and to a limited extent you can do generic algorithms, although the lack of things like operator overloading cripples these from birth. You can't, AFAICS, do some of the funky stuff with traits classes, and things like template metaprogramming, expression templates and Andrei's tricks combining templates and inheritance -- the stuff that's used in several of the best C++ libraries today to give them an edge -- are out of the question for now.
That's a shame, because one of the great things about C++ templates is that using them is pretty easy, but there's quite a bit of power under the hood for people actually implementing class and function templates, such as the designers of those libraries. That means improved performance and/or flexibility for Joe Developers everywhere, even if only a few people know and use the features under the hood.
One of the major plus points of templates is precisely that they don't require you to implement a particular interface by name. Thus they can adapt to any types provided by other parties that provide the necessary interface functions without explicitly saying that they derive from some known base class.
And yes, stripping away the casts is better. It reduces a major class of bugs from run-time to compile-time, and that is a Good Thing.
AAAAAAAAArgh -- missing the point sooo badly
on
Java Gets Templates
·
· Score: 5, Interesting
Sorry, but I'm going to rant now, because every time I see this ill-informed argument it really annoys me.
Operator overloading is a fact of life when you are working with generics. Suppose I want to write a generalised summation method, which adds up all the elements in a list, whether those are int, float, SomeComplexNumberType or whatever. Question: what well-known and easily understood notation would make sense to use when writing this method? Should I write another method called add that has several versions, for each type I'd like to add up? Or maybe it should be addTo? After all, by your own argument, verbose and descriptive names are the way forward. But what if someone else provides a fixed-point type with a method called sum instead? Or maybe a static method taking two fixed-point values called sumOf? Do you see my point here? If everyone uses + to mean +, then writing such code is easy. If everyone uses different notation, which is forced if you don't allow operator overloading, then what you get is unmaintainable crap that cannot take advantage of generics in many of the most useful ways.
Java already has operator overloading anyway. You have + to concatenate strings. You have a conversion operator called toString. You have/ that divides real numbers, but takes the integer part of the result for integral types. The only difference between these and what you have in a language like C++ is that in Java, you can only take advantage of this concept where the Java designers want you to, whereas in C++, you can write your own types at full strength as well.
Yes, operator overloading can be abused. So can method naming (and no, you can't smack the developer on the head, if he happens to work on the other side of the world and you're stuck using his library). But op overloading is more than mere syntactic sugar, where generic programming is involved. There are accepted standards for how we write certain concepts such as addition or strict ordering, and operator overloading is necessary to allow user-defined types to meet those standards, and thus to allow well-written generic code to take advantage of parameterised types and such to best effect. Without it, you've got a fabulous canvas, yet nothing but coarse paintbrushes to draw with.
Alas, as is so often the case, I fear the Java community has been too quick to think it understands, and to go for the buzzword feature without investigating the supports deeply enough. Parameterised types are a good start, and I'm glad to see them included, but I suspect that with experience, there'll be some serious enhancements in a couple of revisions' time...
I feel your pain about getting XML/XSLT things working. Alas, until recently, Moz didn't handle basics like xsl:number properly, and the suggested workaround was "don't use it". Um... no. That made Moz pretty much useless for any serious XML/XSLT work I was doing. Apparently, that particular gremlin was a well-known one, and should be fixed in Moz 1.2, though, so maybe things are coming around slowly but surely...
Re:u r abbreviating pointlessly
on
Equilibrium
·
· Score: 2
<sigh> I knew there was a reason I usually ignored these threads. My sentence is grammatically correct UK English, although I elided the formally correct word "be" before "understood" as is the common usage.
Of course, if you'd actually read and understood my post instead of instinctively flaming, you would have realised that that wasn't my point at all anyway. As long as something is readable, I have no problem with it, and I was neither replying to the original post nor criticising it. My point was simply that if you get too "clever" with the shorthand, it ceases to be readable to many of your audience and projects a bad impression, and this is a point in agreement with the spirit of the parent post.
Of course, since you're posting as an AC and your flame itself contained several spelling mistakes and grammatical errors, you make the point about credibility and projecting a bad image more beautifully than either I or the poster to whom I responded possibly could.
Re:u r abbreviating pointlessly
on
Equilibrium
·
· Score: 2
I don't normally contribute to threads like this one, but...
I help out on a few technical boards for software developers. Most people who post there are quite literate, but obviously if beginners are asking for help, they tend not to know the subject very well yet, and consequently have trouble describing exactly what their problem is. Generally, they do well enough for the more experienced guys to work out what they're looking for and help.
However, occasionally someone tries to be clever, and writes some incomprehensible shorthand rubbish. These people not only come across badly, it's also almost impossible to help them. Often someone points this out, politely and fairly, and gets some sort of rant like several in this thread about how the responder isn't L337 enough to be there, yada yada.
I only mention this to point out that while it's true that language evolves, there's a reason for literacy, and it's to make you understood. If u r 2 k00l n u write L337 SMS sp33k and not good, clear English, then you will not be understood, and people will just ignore you at best, or, more likely, get irritated and ask you to write in English.
I'll see your Morrowind and raise you Quake (the original, and still the best). RPGs are great fun, but for sheer time-wasting, prep'ing for a clan deathmatch on a Quake DM level could take a week just to sort out team tactics. An entire generation of students from a prominent UK university where I studied lost many early hours to that one. Some allegedly made the UK national team but failed their degrees... <sigh>:-)
I'm not sure that's entirely true. My theory is that, for all the Moz team's usually excellent efforts, 1.2b was awful and they should have released a 1.2c (if only, as others have suggested, as a "release candidate"). I downloaded 1.2b myself, intending to test out some fixes in the XSLT stuff I'd been waiting for. Unfortunately, it failed to render even basic pages properly several times in a typical browsing session, and I uninstalled it and reverted to 1.1 within an hour.
Still more unfortunately, I didn't have any useful concrete information to send them, and even if I had, I don't have anything set-up to use Bugzilla. It would be really helpful if there were a "report bug" menu option in test releases of Moz that did all of that for you, rather than expecting Joe Average User to (a) know Bugzilla exists and (b) take the time to use it. Just MHO, of course. (If there is one and I've just never found it, someone please supply a link!)
Lesson: you can do (almost) everything right, use proper methodologies, test early and often, have a team of brilliant people, etc., and still you can have problems.
Sad, but alas true.
I don't think you give yourselves enough credit, though. OK, the memory leak was careless on someone's part, both in the fact that your techniques/tools allowed it in the first place, and in the fact that you didn't run a decent checker on the finished product. But if that's the worst you found in the first few months in an app on the scale I imagine you were dealing with, you did remarkably well, and I'd say your methods were a great success.
I've found that the more versions of the code there are (requirements, user docs, code itself, tests etc.) that are kept truly consistent, the more likely it is you will not make mistakes in the final expression (the code you ship).
I've found that the fewer versions of the code there are at all, the fewer cock-ups happen.
Most documentation that gets printed out is a waste of time. Make the damn code its own documentation, at least as far as implementation details and such. Keep the printed stuff to be higher level overviews of the design -- the big picture -- and for describing the key algorithms and concepts. This way, others on the team or new joiners have somewhere to start and a frame of reference when they check the details (which are described by comments in the code, or indeed the code itself) but you don't waste massive amounts of time writing a silly document that just describes what every method of every class does. We have tools to do that for us; they're called comments.:-)
(By the way, notice that simple refactoring rarely changes any of these higher-level overviews. If you're doing something significant enough that it does, it probably justifies a quick review of the overall design and a suitable update to the document anyway.)
Aside from higher level design docs and feature specs, about the only non-code documents that are often justified are requirements specs and acceptance test specs, which should usually be written in the language of your application domain and not in software terms anyway, and which should be completely independent of the code. On some projects, other forms of testing might usefully be documented as a kind of checklist, but often automated unit tests remove most of the need for this.
So, there you go: I have exactly one version of the code, and it's the code. There might be high-level summaries of features, or some details of the algorithms the code implements, documented as well, but they are somewhat independent. Everything else is for the customer, and totally independent of the code. If you've never tried working this way, and come from a "heavyweight process" environment, try it some time. I'd bet good money you'd prefer it.:-)
Their problem is, it's very difficult for them to tell if refactoring was actually worth it - their developers start with a program that does A, they stop working on new features for the next release for 3 months, and they come back with a program that still does A ("but better!").
S'funny, most of my refactorings take about three minutes, and come back with a program that still does A exactly the same (but better organised).
Occasionally, as I've done over the past couple of days, I do spend several hours rewriting a piece of spaghetti into manageable form, just so I can sensibly work with it. I am, at this moment, the living embodiment of the poor soul who is fated to work with hack-on-hack code forever, such that every little change he makes that logically is fine actually causes a different result in the fifteenth decimal place.
This is the sort of time when refactoring is essential, and of course, if the code has been refactored in small increments along the way, it would never have reached SpagCon 5 and required me to do a big refactor now...
The only catch, alas, is that now my nice systematic code has to have special cases in to reproduce exactly the behaviour the old spaghetti had in relevant cases, right down to that error in the fifteenth place.:-(
A serious question: How can someone really consider themselves a professional programmer - particular one that's been coding for 6 years - but has stuck to one language and one OS.
That depends on your point of view, I guess.
I've been a full-time professional developer for around four years, and I've used predominantly C++ on MS Windows in that time. Sure, I've also used C and assembler skills in significant amounts along the way, I've picked up enough of things like Java and Perl to be useful, and I have a side interest in several other tools and languages as well. The current project I'm working on runs on about 15 different platforms, too.
I'd still probably describe myself as a C++ programmer who works with Windows as a one-line summary, though.
You hit the problem there pretty much head on. Good code is subjective, at least to an extent. There's probably no such thing as perfect code, but most good programmers would probably agree fairly consistently on what is good code and what is not. However, their benchmark may not be the same as a user or their manager.
To me, good code is simply the input that makes a good product, and a good product is simply one that helps me to do something. The more it helps me, the better it is. That may mean running faster, or covering more different cases, or intercommunicating with other products, or any number of other things, depending on my requirements. Furthermore, those requirements may change over time.
Now, from a software developer's point of view, in order to write such good code, you have to follow certain basic rules. You need the code you write to be correct (giving the right answer, with no bad output, and usually with graceful handling of bad input as well). If you're going to keep up with changing requirements, or fix bugs that come to light, you also need your code to be maintainable (so that a developer can find his or her way around it, and adjust it to meet new requirements or fix deficiencies, without compromising the overall standard of the code or expending undue amounts of effort in the process). Correctness and maintainability in turn lead to various typical rules of thumb about commenting well, having a clear design, using meaningful names for things, etc.
I rather suspect, though, that if anything like this ever came to fruition, the holier-than-thou L337 developers would look at things backwards, and see those rules of thumb as indicators of code quality. Lacking any insight into the processes and people behind the code, they will try to do the impossible by reading everything from just those rules of thumb, and judge accordingly. Sadly, this would lead to what are actually quite good and well-managed projects being criticised because the code output does not meet Joe Public's Handbook of Rules of Thumb, page 173, paragraph 2. The fact that that code might correctly and efficiently implement the best algorithm in the world for medical research would be lost on many of them, and the damage would be irreparable for years.
If somebody lifts the look and functionality of some closed-source app, and you suspect infringement, how do you prove it?
If it's closed source, it's very unlikely to be infringement, and there are different rules covering behaviour anyway. Not that the US patents office is much to be proud of, but that's a different issue.
Have the source out there would actually make things easier, not harder. As a TA I had tools to check for "copy and replace variable names", all nicely automated and such.
You miss the point completely.
The problem is not some guy doing a quick search and replace across the source. The problem is when your code embodies trade secrets, such as algorithms you've researched and developed yourself. If your competitors can just read off your algorithms, reimplementing them in some completely different form, or even in a completely different language, is easy. No five-minute tool by a TA is going to help with that. In fact, none of the points addressed in either of the original articles really picks up on this, which to me was the first big stumbling block that came to mind.
The problem with Windows isn't single-user mode, it's the fact that it's vastly over-spec'd and everything is on by default.
If e-mail readers just read text messages and let you write them back, and web browsers just displayed HTML instead of automagically downloading and installing stuff, and you didn't default to running with any TCP/IP port you like available, and so on, then any single-user OS could still be secure.
The problem is the way power has spread without adequate control. They invented ActiveX, based it around a non-secure model, and then let web browsers use it, instead of just rendering HTML. Then they made the e-mail client accept HTML mails, using the same rendering engine, so now someone just has to send you a mail, rather than you actively visiting a site. They gave the e-mail client a preview pane, and switched it on by default, so now the software has a chance to do its damage not only if I actively do something like visit a particular web site, but even if I fail to actively switch it off.
The same story happens all over the place in Windows, and is behind nearly major security cock-up out of Redmond in the last several years. You'd think they'd have learned, but then they'd have had to unbundle IE.
The advantage of open source is not only that you can read the code, but that anybody can.
But how is that, in itself, an advantage? If I buy a closed source product, I'm trusting that the developers have spent time looking over it to weed out any gremlins. With an open source product, unless I'm going to do it myself (which is rarely going to be the case) I'm trusting to others to do it then instead, and this time, the others are mostly volunteers in the same position as me already.
Because of this, you can be somewhat more sure that development will continue for at least as long as you need it.
I'm sorry, but I fail to see how that follows at all.
I don't think that open source proponents automatically assume that a closed source alternative is worse in every way.
Are you new around here?;-)
Seriously, I realise that open source potentially has many advantages. I was just responding to yet another slashbot post by someone who seems to think that OS => better and closed source => worse, and is apparently prepared to rule out what might be an excellent software product just because it's closed source.
I agree that good libraries can be a big help. I think the key thing is that it takes only a small number of very good people to produce a very good library, while many competent-but-nothing-special people will benefit from that work. Java is surely the prime example, where many not particularly skilled Java programmers do little other than stringing together standard library calls, yet they still manage to produce decent work that gets the job done. It'll probably never be as good a job as a more skilled developer could have done, but it'll be a much better job than that particular guy would have done if he'd written it from scratch instead of using a library. We can't all be the best programmer in the world, so that's a very valuable thing.
I can't help feeling that this post is off the mark.
The issue isn't software complexity, it's how well the software does its job, which is helping real people to do something more easily.
Yes, it's true that one drive individual used to be able to write full packages. Of course, that's still true. Many of the best tools I use look every bit as professional as the mass-developed, highly-complex things, and work at least as well, yet were developed by a single enthusiastic person. They have a smaller scope, but on the flip side, they tend to do their one job very well.
As for collapsing into mayhem... You are more generous about current software than I am. When did MS-DOS or WordPerfect 5.1 ever crash and lose your last hour's work? Yes, yes, they weren't multitaskingGUIfrontendmousewavingbizapps(TM), but they let me write my letters, booted in a heartbeat and didn't keep asking me if I wanted fries^H^H^H^H^Hhelp with that. I accept that today's software tries to do much more, but it's hardly an exemplary field for progress in an engineering discipline.
Oh, and WinXP is so much less stable than Win2K it's not funny. I speak from direct personal experience, on several different machines at several different places. Win2K was the one MS got right. WinXP was the candy-covering they forgot to taste before they put it in the shop.
Having said all of this, I do think software development has advanced a lot as a field. I just don't think your argument justifies that conclusion in itself.
Quality software comes only from quality developers--people, not methods or schools of thought or books by really smart people.
I disagree somewhat. Good practices can make a sub-standard team into a gets-it-done-well-enough team, or a good team into a great team. They won't turn a lousy team into a great team, but you'll never have a great team with them, either.
Since quality developers are rare (like Leonardo DaVinci rare), quality software is correspondingly rare.
I disagree with that as well. There are plenty of good developers out there. The problem is invariably that management fails to acknowledge the nature of good developers, usually in one of two big ways.
You have to give them good compensation, because if you don't, someone else will. They more than make up for it with the long term quality they provide; you might reasonably take that as the definition of a good developer, in fact.
You have to let them do their job. Give them management and practices that work with them, not against them. I've seen way too many professional developers who were technically excellent and had an exemplary attitude, but who never met their potential because they were forced to use overweight procedures, or to follow a coding standard set by an old fashioned senior guy who didn't notice things changed in the past decade, or whatever.
If management could get over its short-termism and help good developers to develop well, then they'd find that such people really aren't that rare at all. There are a few in every company I've ever worked at, and I've worked on some teams that consisted almost entirely of high calibre people. But just having a team of good guys isn't enough; this is why good management is worth what you pay for it. Kinda like good developers, when you think about it...:-)
Unfortunately, that breaches the EULA(TM) of Microsoft Security Holes(R) 1.0, to which you agreed when someone else's software installed a service pack on your machine without telling you. Furthermore, disclosure of the technique, and any performance benchmark results associated with it, is also forbidden by the EULA(TM) to Microsoft Unrelated And Unnecessary(R) 2002, to which you agreed when you installed Microsoft Where We'd Like You To Go Today(R) 1997.
Don't worry about the lawyers, just send the compensation to minimise your loss. Microsoft EULA(TM) Breaches Dept now accepts cheques, cash, souls and all major credit cards.
Slashdot Mirror
Perhaps my terminology isn't the norm in the Java world, but nonetheless, what you have is exactly the same as a conversion operator in other languages. It is a means of implicitly converting between types. Except that in Java, you can only set that up for conversion to a String implicitly. (Don't even get me started on why all classes should have to provide this method in the first place, or on the common root class flamefest.)
Really? What's a class, then?
Lisp has an accepted standard of its own: (+ 1 2) is the sum of the numbers 1 and 2. The point is not a universal notation, but a consistent notation within the language, which allows you to write a generic method once that can work with any suitable type without further modification.
Your example is particularly ironic because Lisp's S-expressions are a prime example of exactly the sort of uniform syntax I'm advocating here.
With respect, I think you miss the point as well. The fact that Java treats primitive types differently from those derived from Object is already a serious thorn in the side of many a programmer. This sort of generic feature could provide a systematic, uniform way of dealing with such types, banishing the need to use bastardisations like Integer to a much smaller range of applications. This, IMHO, is a Good Thing.
You're quite right, of course, that it doesn't make sense to try to add an apple and the colour purple. What you're ignoring is that you simply wouldn't provide an addition operator taking a Bicycle and an Orange, and thus trying to do add them with a generic function could and should result in a compile-time error, or at least a run-time error if you're relying on late binding. There is no problem here; at worst it's the same as what you've got if you do the same thing in non-generic code now.
Since no-one has yet pointed it out that I can see, it should be noted that what we're talking about here is parameterised types, and to a limited extent, parameterised methods. This is still quite some way from what you can do with serious generics in other languages.
There is an obvious comparison with C++ templates here, and although those are not the best generics around themselves, they do have a few very useful tricks up their sleeves. In Java, you can now do parameterised containers, and to a limited extent you can do generic algorithms, although the lack of things like operator overloading cripples these from birth. You can't, AFAICS, do some of the funky stuff with traits classes, and things like template metaprogramming, expression templates and Andrei's tricks combining templates and inheritance -- the stuff that's used in several of the best C++ libraries today to give them an edge -- are out of the question for now.
That's a shame, because one of the great things about C++ templates is that using them is pretty easy, but there's quite a bit of power under the hood for people actually implementing class and function templates, such as the designers of those libraries. That means improved performance and/or flexibility for Joe Developers everywhere, even if only a few people know and use the features under the hood.
One of the major plus points of templates is precisely that they don't require you to implement a particular interface by name. Thus they can adapt to any types provided by other parties that provide the necessary interface functions without explicitly saying that they derive from some known base class.
And yes, stripping away the casts is better. It reduces a major class of bugs from run-time to compile-time, and that is a Good Thing.
Sorry, but I'm going to rant now, because every time I see this ill-informed argument it really annoys me.
Operator overloading is a fact of life when you are working with generics. Suppose I want to write a generalised summation method, which adds up all the elements in a list, whether those are int, float, SomeComplexNumberType or whatever. Question: what well-known and easily understood notation would make sense to use when writing this method? Should I write another method called add that has several versions, for each type I'd like to add up? Or maybe it should be addTo? After all, by your own argument, verbose and descriptive names are the way forward. But what if someone else provides a fixed-point type with a method called sum instead? Or maybe a static method taking two fixed-point values called sumOf? Do you see my point here? If everyone uses + to mean +, then writing such code is easy. If everyone uses different notation, which is forced if you don't allow operator overloading, then what you get is unmaintainable crap that cannot take advantage of generics in many of the most useful ways.
Java already has operator overloading anyway. You have + to concatenate strings. You have a conversion operator called toString. You have / that divides real numbers, but takes the integer part of the result for integral types. The only difference between these and what you have in a language like C++ is that in Java, you can only take advantage of this concept where the Java designers want you to, whereas in C++, you can write your own types at full strength as well.
Yes, operator overloading can be abused. So can method naming (and no, you can't smack the developer on the head, if he happens to work on the other side of the world and you're stuck using his library). But op overloading is more than mere syntactic sugar, where generic programming is involved. There are accepted standards for how we write certain concepts such as addition or strict ordering, and operator overloading is necessary to allow user-defined types to meet those standards, and thus to allow well-written generic code to take advantage of parameterised types and such to best effect. Without it, you've got a fabulous canvas, yet nothing but coarse paintbrushes to draw with.
Alas, as is so often the case, I fear the Java community has been too quick to think it understands, and to go for the buzzword feature without investigating the supports deeply enough. Parameterised types are a good start, and I'm glad to see them included, but I suspect that with experience, there'll be some serious enhancements in a couple of revisions' time...
I feel your pain about getting XML/XSLT things working. Alas, until recently, Moz didn't handle basics like xsl:number properly, and the suggested workaround was "don't use it". Um... no. That made Moz pretty much useless for any serious XML/XSLT work I was doing. Apparently, that particular gremlin was a well-known one, and should be fixed in Moz 1.2, though, so maybe things are coming around slowly but surely...
<sigh> I knew there was a reason I usually ignored these threads. My sentence is grammatically correct UK English, although I elided the formally correct word "be" before "understood" as is the common usage.
Of course, if you'd actually read and understood my post instead of instinctively flaming, you would have realised that that wasn't my point at all anyway. As long as something is readable, I have no problem with it, and I was neither replying to the original post nor criticising it. My point was simply that if you get too "clever" with the shorthand, it ceases to be readable to many of your audience and projects a bad impression, and this is a point in agreement with the spirit of the parent post.
Of course, since you're posting as an AC and your flame itself contained several spelling mistakes and grammatical errors, you make the point about credibility and projecting a bad image more beautifully than either I or the poster to whom I responded possibly could.
I don't normally contribute to threads like this one, but...
I help out on a few technical boards for software developers. Most people who post there are quite literate, but obviously if beginners are asking for help, they tend not to know the subject very well yet, and consequently have trouble describing exactly what their problem is. Generally, they do well enough for the more experienced guys to work out what they're looking for and help.
However, occasionally someone tries to be clever, and writes some incomprehensible shorthand rubbish. These people not only come across badly, it's also almost impossible to help them. Often someone points this out, politely and fairly, and gets some sort of rant like several in this thread about how the responder isn't L337 enough to be there, yada yada.
I only mention this to point out that while it's true that language evolves, there's a reason for literacy, and it's to make you understood. If u r 2 k00l n u write L337 SMS sp33k and not good, clear English, then you will not be understood, and people will just ignore you at best, or, more likely, get irritated and ask you to write in English.
I'll see your Morrowind and raise you Quake (the original, and still the best). RPGs are great fun, but for sheer time-wasting, prep'ing for a clan deathmatch on a Quake DM level could take a week just to sort out team tactics. An entire generation of students from a prominent UK university where I studied lost many early hours to that one. Some allegedly made the UK national team but failed their degrees... <sigh> :-)
Is that your professional legal opinion? ;-)
I'm not sure that's entirely true. My theory is that, for all the Moz team's usually excellent efforts, 1.2b was awful and they should have released a 1.2c (if only, as others have suggested, as a "release candidate"). I downloaded 1.2b myself, intending to test out some fixes in the XSLT stuff I'd been waiting for. Unfortunately, it failed to render even basic pages properly several times in a typical browsing session, and I uninstalled it and reverted to 1.1 within an hour.
Still more unfortunately, I didn't have any useful concrete information to send them, and even if I had, I don't have anything set-up to use Bugzilla. It would be really helpful if there were a "report bug" menu option in test releases of Moz that did all of that for you, rather than expecting Joe Average User to (a) know Bugzilla exists and (b) take the time to use it. Just MHO, of course. (If there is one and I've just never found it, someone please supply a link!)
Sad, but alas true.
I don't think you give yourselves enough credit, though. OK, the memory leak was careless on someone's part, both in the fact that your techniques/tools allowed it in the first place, and in the fact that you didn't run a decent checker on the finished product. But if that's the worst you found in the first few months in an app on the scale I imagine you were dealing with, you did remarkably well, and I'd say your methods were a great success.
I've found that the fewer versions of the code there are at all, the fewer cock-ups happen.
Most documentation that gets printed out is a waste of time. Make the damn code its own documentation, at least as far as implementation details and such. Keep the printed stuff to be higher level overviews of the design -- the big picture -- and for describing the key algorithms and concepts. This way, others on the team or new joiners have somewhere to start and a frame of reference when they check the details (which are described by comments in the code, or indeed the code itself) but you don't waste massive amounts of time writing a silly document that just describes what every method of every class does. We have tools to do that for us; they're called comments. :-)
(By the way, notice that simple refactoring rarely changes any of these higher-level overviews. If you're doing something significant enough that it does, it probably justifies a quick review of the overall design and a suitable update to the document anyway.)
Aside from higher level design docs and feature specs, about the only non-code documents that are often justified are requirements specs and acceptance test specs, which should usually be written in the language of your application domain and not in software terms anyway, and which should be completely independent of the code. On some projects, other forms of testing might usefully be documented as a kind of checklist, but often automated unit tests remove most of the need for this.
So, there you go: I have exactly one version of the code, and it's the code. There might be high-level summaries of features, or some details of the algorithms the code implements, documented as well, but they are somewhat independent. Everything else is for the customer, and totally independent of the code. If you've never tried working this way, and come from a "heavyweight process" environment, try it some time. I'd bet good money you'd prefer it. :-)
S'funny, most of my refactorings take about three minutes, and come back with a program that still does A exactly the same (but better organised).
Occasionally, as I've done over the past couple of days, I do spend several hours rewriting a piece of spaghetti into manageable form, just so I can sensibly work with it. I am, at this moment, the living embodiment of the poor soul who is fated to work with hack-on-hack code forever, such that every little change he makes that logically is fine actually causes a different result in the fifteenth decimal place.
This is the sort of time when refactoring is essential, and of course, if the code has been refactored in small increments along the way, it would never have reached SpagCon 5 and required me to do a big refactor now...
The only catch, alas, is that now my nice systematic code has to have special cases in to reproduce exactly the behaviour the old spaghetti had in relevant cases, right down to that error in the fifteenth place. :-(
That depends on your point of view, I guess.
I've been a full-time professional developer for around four years, and I've used predominantly C++ on MS Windows in that time. Sure, I've also used C and assembler skills in significant amounts along the way, I've picked up enough of things like Java and Perl to be useful, and I have a side interest in several other tools and languages as well. The current project I'm working on runs on about 15 different platforms, too.
I'd still probably describe myself as a C++ programmer who works with Windows as a one-line summary, though.
Darn, where are my mod points today? ;-)
You hit the problem there pretty much head on. Good code is subjective, at least to an extent. There's probably no such thing as perfect code, but most good programmers would probably agree fairly consistently on what is good code and what is not. However, their benchmark may not be the same as a user or their manager.
To me, good code is simply the input that makes a good product, and a good product is simply one that helps me to do something. The more it helps me, the better it is. That may mean running faster, or covering more different cases, or intercommunicating with other products, or any number of other things, depending on my requirements. Furthermore, those requirements may change over time.
Now, from a software developer's point of view, in order to write such good code, you have to follow certain basic rules. You need the code you write to be correct (giving the right answer, with no bad output, and usually with graceful handling of bad input as well). If you're going to keep up with changing requirements, or fix bugs that come to light, you also need your code to be maintainable (so that a developer can find his or her way around it, and adjust it to meet new requirements or fix deficiencies, without compromising the overall standard of the code or expending undue amounts of effort in the process). Correctness and maintainability in turn lead to various typical rules of thumb about commenting well, having a clear design, using meaningful names for things, etc.
I rather suspect, though, that if anything like this ever came to fruition, the holier-than-thou L337 developers would look at things backwards, and see those rules of thumb as indicators of code quality. Lacking any insight into the processes and people behind the code, they will try to do the impossible by reading everything from just those rules of thumb, and judge accordingly. Sadly, this would lead to what are actually quite good and well-managed projects being criticised because the code output does not meet Joe Public's Handbook of Rules of Thumb, page 173, paragraph 2. The fact that that code might correctly and efficiently implement the best algorithm in the world for medical research would be lost on many of them, and the damage would be irreparable for years.
If it's closed source, it's very unlikely to be infringement, and there are different rules covering behaviour anyway. Not that the US patents office is much to be proud of, but that's a different issue.
You miss the point completely.
The problem is not some guy doing a quick search and replace across the source. The problem is when your code embodies trade secrets, such as algorithms you've researched and developed yourself. If your competitors can just read off your algorithms, reimplementing them in some completely different form, or even in a completely different language, is easy. No five-minute tool by a TA is going to help with that. In fact, none of the points addressed in either of the original articles really picks up on this, which to me was the first big stumbling block that came to mind.
We respectfully disagree.
Love and hugs,
Steve and Bill.
The problem with Windows isn't single-user mode, it's the fact that it's vastly over-spec'd and everything is on by default.
If e-mail readers just read text messages and let you write them back, and web browsers just displayed HTML instead of automagically downloading and installing stuff, and you didn't default to running with any TCP/IP port you like available, and so on, then any single-user OS could still be secure.
The problem is the way power has spread without adequate control. They invented ActiveX, based it around a non-secure model, and then let web browsers use it, instead of just rendering HTML. Then they made the e-mail client accept HTML mails, using the same rendering engine, so now someone just has to send you a mail, rather than you actively visiting a site. They gave the e-mail client a preview pane, and switched it on by default, so now the software has a chance to do its damage not only if I actively do something like visit a particular web site, but even if I fail to actively switch it off.
The same story happens all over the place in Windows, and is behind nearly major security cock-up out of Redmond in the last several years. You'd think they'd have learned, but then they'd have had to unbundle IE.
But how is that, in itself, an advantage? If I buy a closed source product, I'm trusting that the developers have spent time looking over it to weed out any gremlins. With an open source product, unless I'm going to do it myself (which is rarely going to be the case) I'm trusting to others to do it then instead, and this time, the others are mostly volunteers in the same position as me already.
I'm sorry, but I fail to see how that follows at all.
Are you new around here? ;-)
Seriously, I realise that open source potentially has many advantages. I was just responding to yet another slashbot post by someone who seems to think that OS => better and closed source => worse, and is apparently prepared to rule out what might be an excellent software product just because it's closed source.
I agree that good libraries can be a big help. I think the key thing is that it takes only a small number of very good people to produce a very good library, while many competent-but-nothing-special people will benefit from that work. Java is surely the prime example, where many not particularly skilled Java programmers do little other than stringing together standard library calls, yet they still manage to produce decent work that gets the job done. It'll probably never be as good a job as a more skilled developer could have done, but it'll be a much better job than that particular guy would have done if he'd written it from scratch instead of using a library. We can't all be the best programmer in the world, so that's a very valuable thing.
I can't help feeling that this post is off the mark.
The issue isn't software complexity, it's how well the software does its job, which is helping real people to do something more easily.
Yes, it's true that one drive individual used to be able to write full packages. Of course, that's still true. Many of the best tools I use look every bit as professional as the mass-developed, highly-complex things, and work at least as well, yet were developed by a single enthusiastic person. They have a smaller scope, but on the flip side, they tend to do their one job very well.
As for collapsing into mayhem... You are more generous about current software than I am. When did MS-DOS or WordPerfect 5.1 ever crash and lose your last hour's work? Yes, yes, they weren't multitaskingGUIfrontendmousewavingbizapps(TM), but they let me write my letters, booted in a heartbeat and didn't keep asking me if I wanted fries^H^H^H^H^Hhelp with that. I accept that today's software tries to do much more, but it's hardly an exemplary field for progress in an engineering discipline.
Oh, and WinXP is so much less stable than Win2K it's not funny. I speak from direct personal experience, on several different machines at several different places. Win2K was the one MS got right. WinXP was the candy-covering they forgot to taste before they put it in the shop.
Having said all of this, I do think software development has advanced a lot as a field. I just don't think your argument justifies that conclusion in itself.
I disagree somewhat. Good practices can make a sub-standard team into a gets-it-done-well-enough team, or a good team into a great team. They won't turn a lousy team into a great team, but you'll never have a great team with them, either.
I disagree with that as well. There are plenty of good developers out there. The problem is invariably that management fails to acknowledge the nature of good developers, usually in one of two big ways.
If management could get over its short-termism and help good developers to develop well, then they'd find that such people really aren't that rare at all. There are a few in every company I've ever worked at, and I've worked on some teams that consisted almost entirely of high calibre people. But just having a team of good guys isn't enough; this is why good management is worth what you pay for it. Kinda like good developers, when you think about it... :-)
I'll see your pencil and paper, and raise you a whiteboard, a marker pen and free soft drinks.
Unfortunately, that breaches the EULA(TM) of Microsoft Security Holes(R) 1.0, to which you agreed when someone else's software installed a service pack on your machine without telling you. Furthermore, disclosure of the technique, and any performance benchmark results associated with it, is also forbidden by the EULA(TM) to Microsoft Unrelated And Unnecessary(R) 2002, to which you agreed when you installed Microsoft Where We'd Like You To Go Today(R) 1997.
Don't worry about the lawyers, just send the compensation to minimise your loss. Microsoft EULA(TM) Breaches Dept now accepts cheques, cash, souls and all major credit cards.