Yes, this is an interesting discussion of the behaviour of MS's tools.
But I'd disagree that they show good usability. The behaviour of the user - the way he or she interacts with the application - should be their choice. They should not have to guess how MS (or anyone else, including the KDE team) expect them to behave. If you have to reverse-engineer the thinking behind the software design/implementation, then something's failed. And it's not the user!
Does anyone have a test set to try subversion (or cvs) out with, lying around at the back of a directory somewhere?
Seriously, though, how, other than using it for real, might one test subversion? And how would you recover from the bugs that will be in there without devoting your life to it for a few weeks?
What would you rather do, produce useful software once that does the job, or keep producing versions that purport to do the same thing (with new features) but in fact are all broken heaps of junk?
What would you rather buy/use, working software or junk?
I think there's a big market out there for software that does the job, without needing to be restarted frequently or replaced frequently. And as needs change, process change, data volume increases (...whatever) then new software can and should come in to replace the old stuff.
Re:practical experience implementing compilers??
on
The D Programming Language
·
· Score: 2, Interesting
He's making a more important point, and it's not the wrong way around - he says the specs for C or C++, for example, are so big that the compilers that implement those specs will contain bugs.
And the programmers will have problems writing code that's bug free and uses the best features of the language.
If he can find the right set of features to include in "D" then it'll be easier to learn, easier to write code in, and very importantly, easier to produce compilers for.
to be honest, for me a decent sized screen would have to be double what an average one is right now, with a large one being about the size of a whiteboard (you know, those big things that hang on the wall that you write on). I want something big enough to get several application windows next to each other, rather than stacked one above the other......but of course I'm not willing to pay for it.
Seriously, though, have you ever tried to fit several scientists around one monitor, even, say, a 24" one? It's hard work.
Slashdot Mirror
Yes, this is an interesting discussion of the behaviour of MS's tools.
But I'd disagree that they show good usability. The behaviour of the user - the way he or she interacts with the application - should be their choice. They should not have to guess how MS (or anyone else, including the KDE team) expect them to behave. If you have to reverse-engineer the thinking behind the software design/implementation, then something's failed. And it's not the user!
because the language the tool (ant) is written in is immaterial if it does the job you want it to do.
yes of course I make backups but when testing something that's in alpha, if I'm testing it with real work, I either
a) hope nothing goes wrong (ROFL)
b) backup my personal source tree immediately before each subversion commit step
Because otherwise you can guarantee that when I want to roll back 2 or 3 steps to dig through an issue with my code, I'll hit a bug in subversion.
Now do you get what I was asking? And why?
Maybe next time I'll use a few more words...
Does anyone have a test set to try subversion (or cvs) out with, lying around at the back of a directory somewhere?
Seriously, though, how, other than using it for real, might one test subversion? And how would you recover from the bugs that will be in there without devoting your life to it for a few weeks?
Just wondering.
Graham
What would you rather do, produce useful software once that does the job, or keep producing versions that purport to do the same thing (with new features) but in fact are all broken heaps of junk?
What would you rather buy/use, working software or junk?
I think there's a big market out there for software that does the job, without needing to be restarted frequently or replaced frequently. And as needs change, process change, data volume increases (...whatever) then new software can and should come in to replace the old stuff.
He's making a more important point, and it's not the wrong way around - he says the specs for C or C++, for example, are so big that the compilers that implement those specs will contain bugs. And the programmers will have problems writing code that's bug free and uses the best features of the language. If he can find the right set of features to include in "D" then it'll be easier to learn, easier to write code in, and very importantly, easier to produce compilers for.
to be honest, for me a decent sized screen would have to be double what an average one is right now, with a large one being about the size of a whiteboard (you know, those big things that hang on the wall that you write on). I want something big enough to get several application windows next to each other, rather than stacked one above the other... ...but of course I'm not willing to pay for it.
Seriously, though, have you ever tried to fit several scientists around one monitor, even, say, a 24" one? It's hard work.